Secure Resources with OAuth 2.0
Membrane API Gateway is a full-featured OAuth 2.0 implementation written in Java that can act as authorization server, client and/or proxy for a resource server. It supports the OAuth2 flows:
- Code for Web Application SSO
- Implicit for Javascript clients
- Password for native Applications like mobile apps
- Client credentials for APIs
Through the support of OpenID Connect Core Membrane can also provide:
- Authentication of users
- Detailed user information
- Dynamic registration for clients
The OAuth2 Authorization Framework
OAuth2 offers authorization in a different way than the traditional authorization processes. Instead of registering with every service individually the user registers only with an OAuth2 provider. He can then log in to this OAuth2 provider. After this every other service that trusts this OAuth2 provider can be used. This simplifies the authorization process to only a single registration and login at only one OAuth2 provider instead of doing it for every individual service.
As a consequence the users credentials aren't shared with every service the user wants to interact with and the user only needs to login once for the whole session to use any number of different services.
How the authorization works
The typical OAuth2 authorization flow has multiple parties that interact with each other:
- The user: wants access to a resource and has credentials for authorization.
- The client: acts on behalf of the user and his authorization to make resource requests.
- The authorization server: provides means to register, login, logout, authorize etc.
- The resource: is protected by the OAuth2 authorization flow and accessed on successful authorization.
Suppose the user wants to access a protected resource. He shouldn't be able to access it directly. To reach that resource he uses an OAuth2 authorization flow.
Figure1:
A typical OAuth2 flow could consist of the following steps:
- The user calls the client.
- The client creates an authorization request and redirects the user with that request to the authorization server.
- Now something similar to the traditional authorization process happens: The user is presented with a login screen and needs to login.
- The authorization happens only one time or when the authorization expires.
- The user is now authorized with the authorization provider and the authorization server generates an access code.
- After authorization the user is redirected to the client.
- The access code is given to the client and the client exchanges it for an access token at the authorization server.
- The authorization of the user is expressed as this token. It is bound to and can be used to verify the users authorization.
- Validation of the access token is typically done by the resource itself or sending another request to the authorization server.
This procedure causes that the client and the resource won't have access to the users credentials but can still check authorization by validating the access token.
Picking the right Authorization Flow
There are several scenarios in how one can use OAuth2. Here is a comparison to help you decide which one you need.
Should a user authorize directly with the OAuth2 provider? Then the authorization code or implicit flow are reasonable. The authorization code flow is useful for clients that can keep their client credentials confidential, e.g. your own web server. If you have a public client, e.g. a JavaScript client that is run in the browser you should take the implicit flow.
When the client can be trusted, e.g. an application ran on the users machine, one could either use the password or client credentials flow. Both flows let the client authorize for the user and thus a trust relationship is needed. The password flow uses the users credentials to authorize while the client credentials flow provides anonymous access.
Getting Started
See $MEMBRANE_HOME/examples/oauth2 in the Membrane Service Proxy distribution for working examples
or
read further about the OAuth2 authorization flows.