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 ).

A client is confidential e.g. when the client runs on a protected web server ( client credentials are inaccessible by third-parties ). It is not confidential ( and thus public ) e.g. when your client is downloaded by your user and ran in the user's browser ( the source code is visible and can be searched for the credentials). An example for a public client is a Javascript client that is executed in the browser. But also a C++ programmed native desktop client is public as theoretically the source code is available ( through decompilation ) or the memory of the client can be searched.

The code flow is the most secure. The other flows should only be used when the code flow isn't suitable.

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.

Figure1: The authorization code flow.

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.

Figure2: The implicit flow.

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.

Figure3: The password flow.

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 ).

Figure4: The client credentials flow.

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

Getting Started

See $MEMBRANE_HOME/examples/oauth2 in the Membrane Service Proxy distribution for working examples.