In OAuth 2.0 we have four parties involved. The authorization server - the one who issues access tokens, the resource owner - the one who owns resources, the client - the one who wants to access a resource on behalf of the resource owner, and the resource server - the one who hosts resources and validates all access requests. If you are bit familiar with OAuth 1.0 terminology - this interaction pattern is also known as three-legged OAuth (yes, OAuth 1.0 didn't have a clear separation between the authorization server and the resource server - so only three legs) - and is still the most common OAuth interaction pattern on the web.
Also under OAuth 1.0 terminology - when the resource owner himself becomes the client - this interaction pattern is called 2-legged OAuth. Under OAuth 2.0 you can implement 2-legged OAuth with client credentials grant type.
There is another interaction pattern that has not been discussed so far - where the the client himself becomes the authorization server - and of course the resource owner (no delegation). I would like to call this : 'self-issued access token' pattern (you may be aware of self-issued information cards).
A self-issued access token MUST be self-contained too. What does that mean?
Any self-issued access token should be self-verifiable without talking to a third party to validate. For example, you try to access a resource with a self-issued access token - the resource server should be able to verify the legitimacy of the access token just by looking at it. Self-contained tokens are nothing new. For example, a SAML token is self-contained and self-verifiable. A service provider can guarantee the legitimacy of the token by validating its signature.
How do we make an access token self-contained?
Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature).
Ideally a self-contained access token can be a base64-encoded JWT signed by a key trusted by the resource server.
Even though its a must that a self-issued access token is also a self-contained access token - the reverse is not. A self-contained access token can be issued by an authorization server - signed by it self. At the time of verification the resource server needs not to talk to the authorization server. It can simply validate the token itself by verifying the signature. If the signature is valid and the key used to sign the token is trusted by the resource server - then its a good one.
In the self-issued mode, the token is signed by the client itself - by its own key. The resource server can either trust each and individual key - or it can go for a much scalable PKI. In that case the resource server can trust any key signed by a trusted CA (certificate authority). Since we still use OAuth Bearer token profile, the resource request must be over TLS.
OAuth password grant type was introduced as a replacement for the HTTP Basic Authentication. The self-issued access tokens can be used as a replacement for the TLS mutual authentication.
Also under OAuth 1.0 terminology - when the resource owner himself becomes the client - this interaction pattern is called 2-legged OAuth. Under OAuth 2.0 you can implement 2-legged OAuth with client credentials grant type.
There is another interaction pattern that has not been discussed so far - where the the client himself becomes the authorization server - and of course the resource owner (no delegation). I would like to call this : 'self-issued access token' pattern (you may be aware of self-issued information cards).
A self-issued access token MUST be self-contained too. What does that mean?
Any self-issued access token should be self-verifiable without talking to a third party to validate. For example, you try to access a resource with a self-issued access token - the resource server should be able to verify the legitimacy of the access token just by looking at it. Self-contained tokens are nothing new. For example, a SAML token is self-contained and self-verifiable. A service provider can guarantee the legitimacy of the token by validating its signature.
How do we make an access token self-contained?
Access tokens are credentials used to access protected resources. An access token is a string representing an authorization issued to the client. The string is usually opaque to the client. The token may denote an identifier used to retrieve the authorization information or may self-contain the authorization information in a verifiable manner (i.e., a token string consisting of some data and a signature).
Ideally a self-contained access token can be a base64-encoded JWT signed by a key trusted by the resource server.
Even though its a must that a self-issued access token is also a self-contained access token - the reverse is not. A self-contained access token can be issued by an authorization server - signed by it self. At the time of verification the resource server needs not to talk to the authorization server. It can simply validate the token itself by verifying the signature. If the signature is valid and the key used to sign the token is trusted by the resource server - then its a good one.
In the self-issued mode, the token is signed by the client itself - by its own key. The resource server can either trust each and individual key - or it can go for a much scalable PKI. In that case the resource server can trust any key signed by a trusted CA (certificate authority). Since we still use OAuth Bearer token profile, the resource request must be over TLS.
OAuth password grant type was introduced as a replacement for the HTTP Basic Authentication. The self-issued access tokens can be used as a replacement for the TLS mutual authentication.