Introduction :
OAuth 2.0 defines a framework for securing application access to protected resources (often but not solely identity attributes of a particular user) through Application Programming Interfaces (APIs). There are three primary participants in the OAuth flow. OAuth allows a client (an application that desires information) to send an API query to a resource server (RS), the application hosting the desired information, such that the RS can authenticate that the message was indeed sent by the client. The client authenticates to the RS through the inclusion of an access token in its API message – a token previously provided to the client by an authorization server (AS). In those OAuth scenarios in which the API in question protects access to a user’s identity attributes, it may be the case that the access token will only be issued by the AS after the user has explicitly given consent to the client accessing those attributes.
The OAuth model :
Notwithstanding the above complexity, a useful organizing model for thinking of OAuth 2.0 is:
a. mechanisms by which a client can obtain a security token from an appropriate authority in order to use that token for authenticating a subsequent API call.
b. mechanisms by which a client can present a security token as part of an API call in order to authenticate itself (and thereby enable an authorization decision by the API hosting RS).
The above distinction can be simply described as ‘getting a token’ and ‘using a token.’ These two logical halves of OAuth are shown in the diagram below. The client ‘gets a token’ from the AS and then ‘uses the token’ to authenticate to the RS – behind which is the data the client desires to obtain or manipulate.
OAuth 2.0 defines a framework for securing application access to protected resources (often but not solely identity attributes of a particular user) through Application Programming Interfaces (APIs). There are three primary participants in the OAuth flow. OAuth allows a client (an application that desires information) to send an API query to a resource server (RS), the application hosting the desired information, such that the RS can authenticate that the message was indeed sent by the client. The client authenticates to the RS through the inclusion of an access token in its API message – a token previously provided to the client by an authorization server (AS). In those OAuth scenarios in which the API in question protects access to a user’s identity attributes, it may be the case that the access token will only be issued by the AS after the user has explicitly given consent to the client accessing those attributes.
The OAuth model :
Notwithstanding the above complexity, a useful organizing model for thinking of OAuth 2.0 is:
a. mechanisms by which a client can obtain a security token from an appropriate authority in order to use that token for authenticating a subsequent API call.
b. mechanisms by which a client can present a security token as part of an API call in order to authenticate itself (and thereby enable an authorization decision by the API hosting RS).
The above distinction can be simply described as ‘getting a token’ and ‘using a token.’ These two logical halves of OAuth are shown in the diagram below. The client ‘gets a token’ from the AS and then ‘uses the token’ to authenticate to the RS – behind which is the data the client desires to obtain or manipulate.