Decoding JWT using the API Platform Groovy Policy by Ricardo Ferreira

Introduction

With the explosion of APIs; most of the today’s computing challenges are being driven by it and therefore, new standards had to emerge to make sure that APIs can be used securely, while allowing developers to avoid having to reinvent the wheel every time they implement aspects such as authorization. One good example is JWT (JSON Web Token) which allows API developers to implement authorization – but without requiring that the user credentials be shared across systems. Moreover, JWT can also be signed (by using JWS) and encrypted (by using JWE) which brings even more robustness to the table.

JWT is widely used in the context of OAuth 2.0, which defines a protocol for authorization. Implementing OAuth 2.0 results in an API granting authorization for a given request as long as the request carries a valid token. If the token is valid, the API considers the request authorized and processes it accordingly. This design is simple but very powerful because it eliminates the need to authenticate every single request and more importantly – it eliminates the need to carry the user credentials with the request.

As shown in figure 1, the token is originally obtained from an authorization server that client applications have access to. Once the token is obtained, it can be re-used over multiple API calls as long the token remains valid. Tokens often became invalid due to expiration. Most authorization servers are configured to define an expiration value on every token created. In this context; the API outsources authorization aspects to the authorization server, therefore becoming free of that responsibility. However, the API is still responsible for performing token verification. That can be either implemented directly in the API or, it can be delegated to a gateway layer responsible for exposing the API to the outside world. While nothing can stop a developer from hard coding the token verification in the API code, it is considered a best practice to delegate that task to a gateway layer such as APIPCS. The reason is simple: that way you can promote better agility while building APIs; since this repeatable and error prone coding will be eliminated. Moreover, the APIs will inherit greater robustness regarding token verification since the gateway implements this functionality very efficiently. Read the complete article here.

PaaS Partner Community

For regular information on Oracle PaaS become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.

Blog Twitter LinkedIn Facebook Wiki

Technorati Tags: SOA Community,Oracle SOA,Oracle BPM,OPN,Jürgen Kress