On the other hand, the client might be another web service, and in this case the user will be redirected to the authorization server with the client id, optional scope parameter and redirection URI by the client so that the user can authenticate itself. A appropriate real-life example is Facebook integration on Twitter. Twitter, the client, needs access on protected resources to post your recent tweets on your Facebook timeline. After a successful authentication, the request will be redirected to the clients redirection URI with an authorization code, with which the client can request an access token from authorisation server. In this “authorization code” grant, the client access to the user credentials is not permitted.
Scope defines the boundaries of the authorization. The authorisation server might allow the clients to specify the scope for the access requests with the scope parameter in which scope the access token should be effective. RFC 6749 3.3
Scopes are optional in workflows.
So far, I have covered some essential topics of the OAuth 2.0, that we need to understand to build our enterprise authorization backend. But, there is more. If you are interested in OAuth 2.0 I encourage you to read the RFC 6749. It is in my opinion the most concise document describing the workflows.
Next step, we are going to start building our backend components like Authorization Server, Resource Server, etc. to implement OAuth 2.0 spec and to grant access to our protected resources. The resources are sample REST resources just giving out some important information like “Hello World”.
Upcoming Article: Getting Started with Spring Security