OAuth2 Authorization Flows
The OAuth2 framework supports multiple flows to authorize a user or program. The flows are code, implicit, password and client credentials.
Untrusted and trusted clients
The flows can be split into 2 groups: either the client is trusted or not.
An untrusted client simply means that it has no access to the resource owner's credentials. The user has to provide authorization by authorizing with the authorization server ( the OAuth2 provider ) directly. The client can then authorize as the user without knowing his credentials by using an access token granted by the authorization server.
Untrusted does not, in this context, mean that it is malicious. Untrusted does mean that user interaction is required for authorization.
There are 2 untrusted flows: the code and implicit flows. Untrusted authorization flows provide better security than trusted flows, as the users credentials are never exposed to the client. The code flow additionally never exposes the access token to the user. If this isn't a concern then the trusted flows provide a simplified method of authorization.
Confidential and public clients
A further distinction can be made. Either a client is confidential or it is public. Confidential clients are clients that can hide their client credentials ( client secret or other means of authorization ).
The code flow is the most secure. The other flows should only be used when the code flow isn't suitable.
|public or confidential
|public or confidential
All flows are supported by Membrane Service Proxy and there are working examples illustrating the usage.
Untrusted Authorization Flows
There are 2 untrusted flows: code and implicit. Both need the user to provide authorization through a login dialog.
The code flow
The code flow provides maximum security. The client is confidential, it has no access to the users credentials and it never exposes the access token to the user. It is also the most complex of all flows and requires user interaction.
In this flow the user starts to request a protected resource by calling the client. The client redirects the user to the authorization server for authorization. The user authorizes. An access code is sent to the client, the client exchanges it for an access token. Access to the resource is granted.
For more details see OAuth2 code authorization flow
The implicit flow
The implicit flow is used when the client isn't confidential. The client is public, it has no access to the users credentials but exposes the access token to the user.
In this flow the user starts to request a protected resource by calling the client. The client redirect the user to the authorization server for authorization. The user authorizes. An acces token is sent to the client. Access to the resource is granted.
For more details see OAuth2 implicit flow
Trusted Authorization Flows
The password flow
The password flow is used when the client is trusted. When the client credentials are not accessible the client is confidential else it is public. It has access to the users credentials and exposes the access token to the user.
As a prerequisite to this flow the user has to somehow transfer his/her credentials to the client.
In this flow the clients requests an access token from the authorization server with the users credentials and the client credentials. After that the protected resource is requested ( with the access token appended ). The token validator verifies the access token with the help of the authorization server. Access to the resource is granted.
For more details see OAuth2 password flow
The client credentials flow
The client credentials flow is used when the client is trusted. It is either confidential or public depending on if the client credentials are accessible. It exposes the access token. No user identification possible ( anonymous access ).
In this flow the clients requests an access token from the authorization server with its client credentials. After that the protected resource is requested ( with the access token appended ). The token validator verifies the access token with the help of the authorization server. Access to the resource is granted.
For more details see OAuth2 credentials flow
See $MEMBRANE_HOME/examples/oauth2 in the Membrane Service Proxy distribution for working examples.