Version 1 (modified by Malte, 13 years ago) (diff)

introduction to oauth2 and my soundcloud case

A short overview about the OAUTH language and it's components

In the oauth ietf draft there is a distinction made between an authorization_server and a resource_server.

The case is: We want to enrich and associate a deepamehta-identity with privileges to access resources protected by another authorization_server and stored on another resource_server. So now we have the need to store 1 or 2 types of tokens per user, (can be opaque to the client/user), _after_ the user has granted the deepamehta application authorization for a specific resource_server. see the nice diagram from my case at

To clarify the language of the oauth draft for us: The type of "Authorization Grant" one usually wants to have is called "Authorization Code" (which translates in a request usually to '?grant_type=authorization_code')

To get an "Authorization Code" granted on behalf of a deepamehta-identity as deepamehta-application-developer, an endpoint_uri (?redirect_uri=http...) necessary to facilitate automatic completion to hand over the authorization_code (and skip the need of manually copying and pasting the requested token) should be provided by a deepamehta-authentication-server.

For a good overview to acquire an authorization grant on a users' behalf on a foreign resource_server see also the diagram at and

Types of Tokens

Access Token:

"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. Tokens represent specific scopes and durations of access, granted by the resource owner, and enforced by the resource server and authorization server."

Such an access_token can either..

  • be renewed with every request..
  • or remains valid until it expires and must be reissued by an authorization_server (via a refresh_token or another authorization grant)

Refresh Token:

"Refresh tokens are credentials used to obtain access tokens. Refresh tokens are issued to the client by the authorization server and are used to obtain a new access token when the current access token becomes invalid or expires, or to obtain additional access tokens with identical or narrower scope (access tokens may have a shorter lifetime and fewer permissions than authorized by the resource owner). Issuing a refresh token is optional and is included when issuing an access token. A refresh token is a string representing the authorization granted to the client by the resource owner. The string is usually opaque to the client. The token denotes an identifier used to retrieve the authorization information. Unlike access tokens, refresh tokens are intended for use only with authorization servers and are never sent to resource servers."