OAuth 2 is an authorization framework that enables external applications, systems or other b-2-b services to obtain controller access on an HTTP services, such as AGE plug-in web services, SPMM and other web applications. The framework delegates an access via user authentication to the service that hosts the user account, and authorizes third-party system to access a resource protected by the user's account. The authorization flow of OAuth 2 is easy for implementation and it's applicable in variety of use-cases like web and desktop applications, mobile devices, and for internal b-2-b solutions.
This specification below is specifically designed for application and service-oriented developers, and provides an overview of OAuth 2 roles, protocol flows and the basic principles covered by standard. |
According to RFC 6749, OAuth defines four dedicated roles: 1)Resource Owner - an entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user. 2)Resource Server - the server hosting the protected resources, capable of accepting and responding to protected resource requests using access tokens. 3)Client - an application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices). 4)Authorization Server - The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization. IMPORTANT NOTES: The OAuth 2.0 implementation within AGE acts as a native service under the Authorization Broker of the local node. The Broker handles the tokens management between the Resource Owner and the Resource Server, and acts as Authorization server role. The Resource Owner could be also a part of the Authorization Broker, or the role could be handled by a dedicated third party end-user service. The Resource Server is any system service, plug-in or application managed by AGE. |
 The abstract communication model shown above represents the overall concept of OAuth 2.0 covered by RFC 6749. In a nutshell, the authorization flow consists in the following steps: 1)Firstly, your application (Client) needs to request authorization from the Resource Owner in order to use a protected resource managed by the Resource Server. Optionally, this request may include particular details about the scope of the authorization - what exactly need to be authorized. 2)The Resource Owner authenticates the Client and grants the requested access via special authorization code, and informs the the Broker (Authorization Server) for this action. 3)Once the authorization is granted, your application needs to get a temporary access token in order to use the protected resource. To achieve that, the Client (your application) has to send a request the Authorization Server with the authorization code. 4)The Authorization Server verifies the request and generates a temporary access token. The Broker (Authorization Server) is responsible to manage the generated tokens. 5)Finally, your application is granted and authorized to use the requested resource, and with the access token may send many requests as needed to the Resource Server in accordance with RFC 6750. 6)The Resource Server verifies the token by the Broker, and if exists and it is still valid returns data of the protected resource back to the Client.
The beauty of OAuth 2.0 framework is in the flexibility to simplify and implement this abstract protocol flow in accordance with your particular needs. Nevertheless, to RFC 6749 stipulates the following granting options:
Comparison between these options can be found in "Grant Types" section. IMPORTANT NOTES: In the practice, your application is using particular service or group of services (protected resource, private or enterprise data, etc.) provided by one or more Resource Server(s). These servers can use one or more Authorization Servers. The presumption is that the protected resources are not available for the Client without proper authorization. Respectively, without authorization the Resource Server will actively reject the Client's access by generating HTTP errors. Consequently, the Client need to follow the authorization protocol when such access is required. Therefore, take into consideration that the authorization flow is not a one-time job! There are many situations when the granted access needs to be re-authorized, such as: oThe access token is expired (). oThe Authorization Server is reinitialized, restarted or reloaded for security reasons. oYour application is restarted or for a reason the access token is deleted. oetc. |
