As microservices architecture becomes increasingly prevalent, each microservices cluster is tasked with independently handling identity authentication and authorization. This not only increases the development workload but also gives rise to maintenance and security challenges. However, the introduction of a gateway concept provides an innovative solution to these issues.
VMware Spring Cloud Gateway, acting as the first line of defense for all incoming requests, assumes the crucial responsibility of handling identity authentication, verifying user identities, and validating their permissions. This means that each microservice no longer needs to code authentication and authorization independently, thus reducing the development workload significantly.
Compared with the open source version of Spring Cloud Gateway which is a library that an application developer can use to create their own gateway implementation, VMware Spring Cloud Gateway provides out of the box Single Sign-On feature. With enabling Single Sign-On, Spring Cloud Gateway acts as a centric place to do authentication and authorization, and commercial API route filters for transporting authorized JSON Web Token (JWT) claims to application services. Any unauthenticated incoming request will initiate an authorization code flow. Once the token is acquired by the gateway, it is then used when sending requests to a backend service.
Next will be to explain how to configure Single Sign-On (SSO) using the gateway to address security issues and some advanced topics if you are using Microsoft Entra ID (formerly Azure Active Directory) as an OpenID identify provider.
Oauth2 and Single Sign-On（SSO）
OAuth 2.0, which stands for “Open Authorization”, is a standard designed to allow a website or application to access resources hosted by other web apps on behalf of a user. It addresses the problem of secure and delegated access to user data and resources by enabling third-party applications to access them without exposing the user's credentials.
OAuth 2.0 and Single Sign-On (SSO) are two separate but related concepts that can be combined to provide a more powerful identity authentication and authorization mechanism.
Single Sign-On (SSO) is an authentication mechanism that allows users to authenticate themselves using a set of credentials (such as usernames and passwords) across multiple applications or systems. Users only need to log in once and can automatically access other applications without re-entering their credentials. SSO solves the problem that to simplify the user authentication process, improve user experience, and reduce the burden of remembering multiple credentials.
A common implementation approach is to incorporate OAuth 2.0 as part of an SSO solution. After logging in through SSO, users can utilize their SSO token (such as JWT) to perform the OAuth 2.0 authorization flow and obtain access tokens and ID tokens. This allows achieving the "single sign-on, everywhere access" effect.
Configure Single Sign-On on Spring Cloud Gateway
The following table describes the SSO properties.
| Property | Required? | Description |
issuerUri |
Yes | The URI that's asserted as its issuer identifier. For example, if issuer-uri is https://example.com, an OpenID Provider Configuration Request is made to https://example.com/.well-known/openid-configuration. The result is expected to be an OpenID Provider Configuration Response. |
clientId |
Yes | The OpenID Connect client ID from your identity provider. |
clientSecret |
Yes | The OpenID Connect client secret from your identity provider. |
scope |
Yes | A list of scopes to include in JWT identity tokens. This list should be based on the scopes that your identity provider allows. |
To set up SSO with Microsoft Entra ID, see Set up single sign-on using Microsoft Entra ID for Spring Cloud Gateway and API Portal.
You can use the Azure portal or the Azure CLI to edit SSO properties.
To edit SSO properties in the Azure portal, please select Spring Cloud Gateway on the navigation pane, and then select configuration. Please specify values for the properties listed for SSO. For more details, please refer to Configure Single Sign-On.
More details about Microsoft identity platform
If you are using the Microsoft Entra ID as an OpenID identify provider, below are more details.
The Microsoft identity platform implements the OAuth 2.0 authorization protocol. It helps you build applications your users and customers can sign in to using their Microsoft identities or social accounts. It authorizes access to your own APIs or Microsoft APIs like Microsoft Graph.
The Microsoft identity platform authenticates users and provides security tokens, such as access tokens, refresh tokens, and ID tokens. Security tokens allow a client application to access protected resources on a resource server.
-
Access token
The default lifetime of an access token is variable. When issued, the Microsoft identity platform assigns a random value ranging between 60-90 minutes (75 minutes on average) as the default lifetime of an access token. -
ID token
By default, an ID token is valid for one hour - after one hour, the client must acquire a new ID token. -
Refresh token
Refresh tokens have a longer lifetime than access tokens. The default lifetime for the refresh tokens is 24 hours for single page apps and 90 days for all other scenarios.
When a request arrives at the Spring Cloud Gateway, it can verify the validity of the access token associated with the request. If the access token has expired or become invalid, the gateway has the intelligence to leverage the refresh token to interact with the Identity Provider (IDP). This allows the gateway to seamlessly refresh the access token, keeping your application secure and ensuring uninterrupted access to your services. After the refresh token has expired, Spring Cloud Gateway will require the client to reauthenticate.
As of January 30, 2021 you cannot configure refresh and session token lifetimes. Azure Active Directory no longer honors refresh and session token configuration in existing policies. New tokens issued after existing tokens have expired are now set to the default configuration. You can still configure access, SAML, and ID token lifetimes after the refresh and session token configuration retirement.
If you need to continue to define the time period before a user is asked to sign in again, configure sign-in frequency in Conditional Access. To learn more about Conditional Access, read Configure authentication session management with Conditional Access .
To help you get started, we have monthly FREE grants on all tiers – 50 vCPU Hours and 100 memory GB Hours per tier.
Additional Resources
- Learn using an MS Learn module or self-paced workshop on GitHub
- Deploy your first Spring app to Azure!
- Deploy the demo Fitness Store Spring Boot app to Azure
- Deploy the demo Animal Rescue Spring Boot app to Azure
- Learn more about implementing solutions on Azure Spring Apps
- Deploy Spring Boot apps by leveraging enterprise best practices –Azure Spring Apps Reference Architecture
- Migrate your Spring Boot, Spring Cloud, and Tomcat applications to Azure Spring Apps
- Wire Spring applications to interact with Azure services
- For feedback and questions, please raise your issues on our GitHub.
To learn more about Spring Cloud Azure, we invite you to visit the following links:
- Reach out to us on StackOverflow or GitHub.
- Reference Documentation
- Conceptual Documentation
- Code Samples
- Spring Version Mapping