Published on November 22, 2023

Oauth 2.0

Sharing data between services in the past requires username and password authentication. Once authenticated, the client service will have full access to all the user’s data on the server. This is no longer considered the best practice for exposing username and password credentials, along with the lack of control over how much data to share.

Resource sharing using Oauth 2.0 usually includes three or more parties, the resource owner, resource server, and resource client. Although not required, the resource server can also take on the role of an identity provider.

The resource-sharing process starts with the resource owner requesting resources via the resource client. The client will authenticate with the identity provider (the resource server in this case) by providing a client id and the scope of data being requested. This will forward the owner to a permission dialog where the owner can review what resource is being shared. Once the owner grants the permission, the server will issue an auth token, which the client will use to request an access token. The client can now access resources on the server within the defined scope using the access token. At no point in the Oauth 2.0 process does the owner need to provider their username and password credentials.

Some other notable features of Oauth 2.0 includes the ability for the owner to revoke or set expiration date on the access token.

Access TokenAPI AuthenticationAuthenticationOAuth 2.0TechToken-Based Authentication