This is a service that supports authorization code grant type. The authorization code grant type is used to obtain both access tokens and refresh tokens and is optimized for confidential clients. Since this is a redirection-based flow, the client must be capable of interacting with the resource owner’s user-agent (typically a web browser) and capable of receiving incoming requests (via redirection) from the authorization server. The service accepts user credentials and redirects back authorization code with redirect URI defined in the client registration or overwritten it by passing in a redirect URI in the request. Read More »

This is a post endpoint to get JSON web tokens. Currently, it supports three different grant types: authorization_code, client_credentials and password. It issues subject token to identify the original human caller, access token for the client and refresh token if needed. It also supports token exchange and token chaining for maximum security. In this implementation, we only support JSON Web Token as Simple Web Token is not scaling very well. In a microservices architecture, the tokens must be verified at each service without calling back to the authorization server. Read More »

The service to support federated OAuth 2.0 providers. For example, the external OAuth 2.0 provider is for external clients and the internal OAuth 2.0 provider for internal clients. It is a federation protocol aimed at simplifying authorization and access to protected data by giving access to data while protecting the owner’s account credentials. It allows a user with an account on one website (the service provider) to allow another website (the consumer) to access his or her data from the first website. Read More »

Every microservice or API needs to register itself to OAuth2 server in order to control who can access it. During the registration/on-boarding, a list of scopes defined in the OpenAPI specification or other schema contracts for GraphQL and Hybrid RPC should be populated as well. This list of scopes will be used for clients to register scopes in order to access this particular service or API during client registration. This service has several endpoints and listens to port 6883. Read More »

Before initiating the protocol, the client registers with the authorization server. The method through which the client registers with the authorization server is not defined in OAuth 2.0 specification. As an extension, we have implemented client registration/on-boarding as a microservice that exposes several endpoints. Unlike other OAuth 2.0 providers, we have extended the client registration to define the relationship between client and service (service registers itself) and service’s endpoints. Before digging into the details of implementation, let’s clarify some concepts about the client. Read More »

This is a service for user registration and management. The OAuth server supports integration with other user management systems like active directory or LDAP. However, for most enterprise customers, their customer information normally will be in the database. This service provides a database table for user management and several endpoints to manage users. In OAuth 2.0 specification, a user is normally called the resource owner. User Type Currently there are three user types to support. Read More »

In microservices architecture, the traditional way of copying public key certificates to hosts of services does not work. With container orchestration tools like Kubernetes old containers can be shut down and new containers can be started at any time. The push certificates to services have to be changed to pull certificates from OAuth2 server instead. This service is designed to pull public key certificates based on the keyId that is in the JWT token header. Read More »

Refresh Token is issued in Authorization Code Grant and Resource Owner Password Credentials Grant along with access token. Also, for maximum security, a refresh token is issued every time the old refresh token is used to renew an access token. The token service is responsible for issuing refresh token alone with access token. This service is used to manage the refresh token. For example, all all active refresh tokens, delete/revoke a refresh token or retrieve all information about one particular refresh token. Read More »

OpenID Connect (OIDC) is an authentication layer on top of OAuth 2.0, an authorization framework. The standard is controlled by the OpenID Foundation. OpenID Connect is a simple identity layer on top of the OAuth 2.0 protocol, which allows computing clients to verify the identity of an end-user based on the authentication performed by an authorization server, as well as to obtain basic profile information about the end-user in an interoperable and REST-like manner. Read More »

Public OAuth clients that use the code grant and run on smartphones are susceptible to a code interception attack. Fortunately, this attack can be successfully prevented by establishing a secure binding between the authorisation request and the subsequent token request. The OAuth work group devised an official mini extension of the protocol for that, called Proof Key for Code Exchange (PKCE) and published in September 2015 as RFC 7636. It is a countermeasure against the authorization code interception attack. Read More »

There are four standard grant types in OAuth2 specification, outlining how to add custom grant types. With more and more users asking for some special integration with our OAuth2 services, we are adding the following custom grant types. These are non-standard and will only be used with a special client_type called trusted in most of the cases. For users trying to leverage these grant types, you have to fully understand the risks and you must ensure that the client, the authorization server, and the services it protects reside within the same organization and ideally within the same network. Read More »

The light-oauth2 and oauth-kafka (enterprise version) token service supports the issuer of long-lived bootstrap token for Platform Components integration. The bootstrap token client usually will be the DevOps pipeline, and it will retrieve a bootstrap token during the Kubernetes deployment. Bootstrap Token Here is an example of token generated from the test case. eyJraWQiOiIxMDAiLCJhbGciOiJSUzI1NiJ9.eyJpc3MiOiJ1cm46Y29tOm5ldHdvcmtudDpvYXV0aDI6djEiLCJhdWQiOiJ1cm46Y29tLm5ldHdvcmtudCIsImV4cCI6MTk0NzA3MzQ5NywianRpIjoiVFY4cndsOWpDMEVVMWtmUWV6MFdHZyIsImlhdCI6MTYzMTcxMzQ5NywibmJmIjoxNjMxNzEzMzc3LCJ2ZXJzaW9uIjoiMS4wIiwiY2xpZW50X2lkIjoiZjdkNDIzNDgtYzY0Ny00ZWZiLWE1MmQtNGM1Nzg3NDIxZTAwIiwic2NvcGUiOlsiQThFNzM3NDBDMDA0MUMwM0Q2N0MzQTk1MUFBMUQ3NTMzQzhGOUYyRkI1N0Q3QkExMDcyMTBCOUJDOUUwNkRBMiJdLCJzaWQiOiJjb20ubmV0d29ya250LnBldHN0b3JlLTEuMC4wIn0.TKX_UPjPLkj2AETbDrOyJpPik1qVwU7OzQo4yAqTnesIlqCXW0p7SdJmvnfmgKO-Z6I4YRiroN_MIaRw-pxu5tiKziD_pyrOJJ0KzFQVDKCnVp9nzkbGd64pwH3VQLylTL_wVdU6VdC_pHiBFlvDyAvL9G-Xal1Koe905E_iDJOm5RGhNcm8MQ1VEvIWv31sO7FYKnibjYAnCtTOhHmYHLuHmSe15ID-H_QpC9BHneHLz4CugUZEC2nR5oam_3lmOarNiyNEVG-jv9OmNhJyYffPbSHp7YBCqiC9Z-p3qbTQ-PkxZ5kmZgVrxZlAYkcUZJy2TaJN1PYYARoxlCsdbw Here is the payload of the token. { "iss": "urn:com:networknt:oauth2:v1", "aud": "urn:com.networknt", "exp": 1947073497, "jti": "TV8rwl9jC0EU1kfQez0WGg", "iat": 1631713497, "nbf": 1631713377, "version": "1. Read More »

JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. The payload information can be verified and trusted because it is digitally signed. As JWTs can be signed you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the token payload, you can also ascertain that the content hasn’t been tampered with. Read More »

In most cases, when basic authentication is used, we are going to look up the user profile from a database to verify the hashed/salted password in order to authenticate the user with credentials. For some organizations, they are using Active Directory for user management and everybody logs into a Windows domain. In this environment, it is better to setup SPNEGO/Kerberos so that SSO on the broswer can be done seamlessly. If SPNEGO is not implemented, we can still use LDAP to do the SSO explicitly. Read More »

The light-oauth2 authorization code service supports both SPNEGO/Kerberos and Basic Authentications in HTTP get endpoint /oauth2/code. After being successfully authenticated, an authorization code will be directed back to the Single Page Application. If the SPA does not handle the redirected URI path, then the BFF(backend for frontend) will get the authorization code to complete the authentication and authorization flow on behalf of the SPA. In this flow, the user credentials won’t be revealed to the SPA and the access token won’t be revealed to the SPA running on the browser. Read More »