A web application which wants to gain access to shared resources should redirect the user to a page of the authorization server. When doing so, it informs the authorization server about the access rights it is requesting. This information, which is called Scope, is actually a list of identifiers separated by space characters which are often available as URLs in order to avoid naming conflicts and are given by the resource server.
Consequently, the authorization server asks the user, in his role as resource owner, for authentication (e.g. by providing the username and password). Subsequently, the user can either grant or reject the client’s request. The authorization server then redirects the user to the client and passes the user‘s decision to the client using a URL parameter. If the user has granted the request, the query string contains a code which the client can exchange for a security token. When doing so, the client provides authentication details to the authorization server. Mostly this is also done by giving the username and password.
The token received this way may then be used by the client to gain access to the desired resources via the resource server. Once it has received the token, the resource server must verify its validity and check if it was indeed provided by the named authorization server. Validity can be checked using the expiry date contained within the token and the latter may be done by verifying other evidence which is also embedded in the token. Such evidence may, for example, be a digital signature or an HMAC. If such cryptographic proceedings are to be avoided, there is also the possibility of the resource server contacting the authorization server to confirm the validity of the token.
The token may contain information about the user which might be used by the resource server to verify rights. Alternatively, the token may simply be a key which the resource server may exchange for user-related data when contacting the authorization server.