Most Common architecture's of exposing your API's

Every application created nowadays uses one of the 4 techniques for authentication and authorization.

  • Authentication - User enters username, password and application validates via it’s own database where it store’s username/password.
  • Federated Authentication - Some applications rely on other internal or external services to verify the identity of the user’s. On the web, many applications trust websites like google,facebook to identify the user. In a corporate IT environment, applications may trust active directory server or saml provider to authenticate the users. ex. SAML, OPENID Connect.
  • Authorization - applications usually have logic based on user role. Admin user may have more rights versus normal user.
  • Delegated Authorization - is process where user grants access to another person or application to perform actions on his behalf. OAuth2 works similarly where a user grants access to applications(ex. flickr) to perform actions on the user’s behalf(ex. google).

Below diagrams are most commonly used architectures I have seen in practice while implementing oauth2/openIdConnect/SAML standards.

Resource Owner password Flow

Mostly used for trusted Browser based and mobile applications where front end and backend is owned by same company or entity.

Google AuthSub

Since the entire source code is available to the browser, they cannot maintain the confidentiality of their client secret, so the secret is not used in this case.

When to use:

  • If you or your company owns the users identity (i.e. username,password etc.) and you want to create Mobile or web applications on top of your api’s. Hence, it works great for API driven apps.
  • Can be used in place where API’s are protected by HTTP Basic access authentication. With Basic auth, application has to have access to user’s password continuously in comparison to Resource owner flow where password is required only once.

Authorization Code grant type flow

Mostly used for confidential clients/applications i.e. The applications which can keep client id/secret secure on the server side.

Google AuthSub

Google AuthSub

High level flow is as follows:

When to use:

  • When API security is of utmost importance and the OAuth token shouldn’t be leaked to the browser, where the user may get access to it.

Implicit grant type flow

Mostly used for public clients i.e Mobile Apps / Web Apps using 3rd party authorization.

Google AuthSub

When to use:

  • The browser is strongly trusted and there is limited concern that the access token will leak to untrusted users or applications.

Client Credential flows

Mostly used for private clients/applications where application is the owner of the data it want to read/update.

Google AuthSub

When to use:

  • If an application wants to do CRUD operations on the data stored where application itself is the owner of the data. ex. if application is the owner of some storage api where it can use client credentials issued by API to perform CRUD operations.
  • When a resource owner has granted an application access to their resources out of band. Used only in specific cases.

SAML Based Extension grant

Most commonly used for Single Sign on Scenarios where company does not own the user’s identity (username,password).

References


https://tools.ietf.org/html/rfc6749} https://aaronparecki.com/articles/2012/07/29/1/oauth2-simplified

Version History


Date Description
2015-08-01    Initial Version