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. Oauth 2.0 is an authorization framework that leverages OpenID Connect (OIDC) for authentication. 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 authorization server. The resource-sharing process starts with the resource owner requesting resources via the resource client. The client will invoke the authentication flow with the authorization server (the resource server in this case). This redirects the user to the authorization server where they are presented with a login page. The owner can review what resource is being shared upon successful authentication. Once the owner grants the permission, the authentication 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. Some other notable features of Oauth 2.0 include the ability for the owner to revoke or set expiration date on the access token. Sequence Diagram oidc-oauth2-sequence-diagram

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.