OAuth 2.0 is an open standard for API authorization, which allows us to share information between sites without having to share identity.
It is a Framework that smooths the delegation of client authorization, verifying access to APIs. Therefore, it is not an authentication protocol but the provision of an access token to access a specific resource.
Its purpose is to allow other providers, services or applications to access information without directly providing user credentials.
Authentication and authorization control is given to LinkarWS using Oauth 2.0 and OpenID standards.
The different roles that OAuth 2.0 uses in the process are:
oClients
The application that wants to access the API is called Client.
Before accessing, client must be authorized by the user, and such authorization must be validated by the API.
The client can be a web application, a mobile application, a desktop application, a Smart TV application, an IoT device, another API that consumed from this API, etc.
oResource Owner
On LinkarWS we name it Identity Resources. The owner of the resource is the user who gives authorization to a certain application to access his account and do some things on his behalf.
oAuthorization Server.
The authorization server is responsible of handling authorization requests. It verifies the identity of users and issues a series of access tokens to the client application.
The returned token is of type JWT with the following structure:
oHeader: header indicating, at least, the algorithm and the type of token, which in this case is JWT.
oPayload: where the user data and privileges are described, as well as all the additional information.
oSignature: a signature that allows to verify if the token is valid.
LinkarWS itself performs those functions, although it can also be outsourced to external identity servers, as in the case of the IdentityServer4 Mode that we will see later.
oResource Server
The resource server is the API itself, and in LinkarWS we name it API Resources.
The elements of control for the access to the resources are defined in the Claims and Scopes:
oClaims. Name/value pairs that contain information about a user. They provide a formidable way of trusting that the data is valid and true.
oScopes.Space-separated lists of identifiers used to identify resource access privileges.
The token request is made through the url ../api/v1/{identityresourcename}/token
LinkarWS offers the following Grant Types:
oClient credentials
Intended for server-to-server authentication, this flow describes an approach where the client application acts on its own behalf rather than on behalf of any individual user. In most cases, this flow allows users to specify their credentials in the client application, so they can access the resources under the client's control.
The token request must contain the following data:
oclient_id and client_secret (defined in Clients)
olist of scopes. (defined at the intersection of API Resources, Clients and Identity Resources).
oResource owner password
Requires logging in with username and password. In this case, the credentials will be part of the request. This flow is only suitable for trusted clients (e.g. official applications launched by the API provider).
The token request must contain the following data:
ousername and password (defined in Identity Resources)
oclient_id and client_secret (defined in Clients)
olist of scopes. (defined at the intersection of API Resources, Clients and Identity Resources).
