Documentation
Policies Reference
OAuth 2.0
Description
The OAuth 2.0 policy follows the RFC-6749 standard.
Express Gateway plays the role of both resource server and authorization server. In order to use this policy, consumers
must be created and an oauth2
credential created for them.
The OAuth 2.0 policy will listen on the following global endpoints:
/oauth2/authorize
- Endpoint to provision authorization codes for the Authorization Code flow, or the access token for the Implicit Grant flow. Only POST is supported.
/oauth2/token
- Endpoint to provision access tokens to support the Client Credentials and Password Credentials Grant flows. Only POST is supported.
When a client has been authenticated and authorized, Express Gateway will append property and authentication headers to the request before proxying it to the downstream service, so that you can identify the consumer and the end-user in your service:
Post authentication/authorization headers
If you need to pass some headers to the downstream services, you can use the headers policy.
OAuth 2.0 Flows
There are 3 distinct entities at play -
- Client app (client or application that is registered on Express Gateway that wants to act on behalf of user)
- Express Gateway’s web UI (can be configured and customized by you)
- Express Gateway itself as authorization server
Authorization Code
- Client is already registered with Express Gateway and has an ID, secret and redirect URI in Expres Gateway.
- Client app redirects user to the Express Gateway’s web UI passing its app_id, response_type and scope
- UI makes a GET to
/oauth2/authorize
and Express Gateway ensures user is logged in. - If user is not logged in, he/she logs in on the Express Gateway’s UI. For this login, Express Gateway acts as an authorization server for the user.
Note: The user will need basic-auth credentials to be able to login.
- Express Gateway’s Web app prompts user to allow client access to specific scopes, to which the user grants access.
- Express Gateway’s UI again makes a call to
/oauth2/authorize
with the following data to request an auth code:- Header
- Authorization: basic clientId:secret
- body
clientId
authenticatedUserId
redirectUri
scopes
response_type
- Header
- Express Gateway responds back with whether or not the client is authorized. If authorized, it returns an authorization code and redirect_uri.
- UI redirects the client app to the redirect_uri
- Client App will exchange the
auth_code
for an access token by making a POST to/oauth2/token
Implicit
Implicit grant is the same as authorization code grant, except we return a token and redirect_uri in step 7, and it doesn’t have steps 8 and 9.
Client Credentials
Client credentials grant will follow the standard RFC documentation.
Usage
In order to use the OAuth2 Authorization policy, consumers must be created and oauth2
credentials created for them.
To create consumers (users and apps): use the CLI and create user or create app
command.
To create an oauth2
credential for a user or app: use the CLI and create credential
command with type oauth2
.
To enable the OAuth2 policy, add oauth2
in gateway.config.yml in the policies
section.
policies:
- oauth2
Example
pipelines:
pipeline1:
apiEndpoints:
- authorizedEndpoint
policies:
- oauth2:
- proxy:
- action:
serviceEndpoint: backend
Options Reference
jwt
- JWT signin parameters. For a complete reference, see the jwt policy
- default value:
undefined
passThrough
:- determines whether the gateway should execute the successive policy in case the auth process fails. If set to false,
the gateway will return an
Unauthorized
response. - default value:
false
- determines whether the gateway should execute the successive policy in case the auth process fails. If set to false,
the gateway will return an
JWT support
By default, the oAuth2 server will respond back with an opaque token. This is a token in a proprietary format that typically contain some identifier to information in a server’s persistent storage. To validate an opaque token, the recipient of the token needs to call the server that issued the token.
However, it also supports issuing and veryfing JWT. This might come handy if you have multiple microservies across your data center that need to be authenticated and authorized.
First of all, you’ll need to configure the gateway to issue JSON Web Tokens instead of opaque ones. This can be done in the system.config.yml accessTokens section.
Then, you’ll need to instruct the oauth2
policy to verify JWT.
policies:
- oauth2:
action:
jwt:
issuer: express-gateway
audience: something
subject: test
secretOrPublicKey: ssssst
checkCredentialExistence: false
jwt
parameters are the same listed in the jwt policy
You can see a live example on Glitch
Customizing the UI
The basic implementation of the UI for the OAuth2 policy is found in /lib/policies/oauth2/views
. In this directory,
you can customize the code to suit your needs.