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
Published on October 6, 2023

Username and Password Authentication Using JWT

JWT (JSON Web Token) is a self-contained token that securely encodes information between parties as a JSON object. One of JWT's primary use cases is for authentication in web applications or APIs. User authentication using JWT begins with the client submitting their username and password. Assuming the user exists and the provided credentials are valid, the next step is to issue an access token and a refresh token by signing the username along with metadata, such as an expiration date, using a server private key. The client can then commence using the access token as part of their requests for protected resources. The resource access flow starts with the client attaching their access token in the "Authorization" header. The server verifies the access token with its corresponding server private key and permits the request to proceed if the provided access token is valid. Access tokens have a short lifespan. Once they expire, the client must use the refresh token, which has a much longer lifespan, to obtain a new access token. The refresh token was originally set in the browser's cookie during the initial authentication and is accessible to the server with every request. When the client wishes to refresh their access token, the server verifies their refresh token. Upon successful verification, the server signs a new access token by encrypting the username with a new expiration date using the server private key.

Access TokenAPI AuthenticationAuthenticationJSON Web TokenJWTRefresh TokenTechToken-Based Authentication