Lots of companies are eager to provide their identity provider: Twitter, Facebook, Google, etc. For smaller businesses, not having to manage identities is a benefit. However, we want to avoid being locked into one provider. In this post, I want to demo how to use OpenID Connect using Google underneath and then switch to Azure. OpenID Connect The idea of an open standard started with around 2006. Because of a security issue, OAuth 2.0 superseded the initial version. OAuth 2.0 became an IETF RFC in 2012: authorization OAuth The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. — RFC 7469 — The OAuth 2.0 Authorization Framework OAuth focuses mostly on ; the part is pretty light: it contains a section about Client Password authentication and one Other Authentication Methods. authorization authentication The authorization server MAY support any suitable HTTP authentication scheme matching its security requirements. When using other authentication methods, the authorization server MUST define a mapping between the client identifier (registration record) and authentication scheme. — 2.3.2. Other Authentication Methods OpenID Connect uses OAuth 2.0 and adds the part: authentication OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the 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. OpenID Connect allows clients of all types, including Web-based, mobile, and JavaScript clients, to request and receive information about authenticated sessions and end-users. The specification suite is extensible, allowing participants to use optional features such as encryption of identity data, discovery of OpenID Providers, and logout, when it makes sense for them. — What is OpenID Connect? Here are a couple of identity providers that are compatible with OpenID Connect: GitHub Google Microsoft Apple Facebook Twitter Spotify In the following, we will start with Google and switch to Azure to validate our setup. Setting up OpenID Connect With Apache APISIX Imagine we have a web app behind Apache APISIX that we want to secure with OpenID Connect. Here’s the corresponding Docker Compose file: version: "3" services: apisix: image: apache/apisix:3.1.0-debian #1 ports: - "9080:9080" volumes: - ./apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro #2 - ./apisix/apisix.yml:/usr/local/apisix/conf/apisix.yaml:ro #3 env_file: - .env httpbin: image: kennethreitz/httpbin #4 Apache APISIX API Gateway APISIX configuration — used to configure it statically in the following line. Configure the single route. Webapp to protect. Any will do. Apache APISIX offers a plugin-based architecture. One such plugin is the plugin, which allows using OpenID Connect. OpenID-connect Let’s configure it: routes: - uri: /* #1 upstream: nodes: "httpbin:80": 1 #1 plugins: openid-connect: client_id: ${{OIDC_CLIENTID}} #2 client_secret: ${{OIDC_SECRET}} #2 discovery: https://${{OIDC_ISSUER}}/.well-known/openid-configuration #2#3 redirect_uri: http://localhost:9080/callback #4 scope: openid #5 session: secret: ${{SESSION_SECRET}} #6 #END Catch-all route to the underlying web app. Plugin configuration parameters. Values depend on the exact provider (see below). OpenID Connect can use a Discovery endpoint to get all necessary OAuth endpoints. See for more information. OpenID Connect Discovery 1.0 spec Where to redirect when the authentication is successful. It mustn’t clash with any of the explicitly defined routes. The plugin creates a dedicated route there to work its magic. Default scope. Key to encrypt session data. Put whatever you want. Configuring Google for OIDC Like all Cloud Providers, Google offers a full-fledged Identity Management solution, which may be daunting for newcomers. In this section, I’ll only detail the necessary steps required to configure it for OIDC. On the , create a dedicated project (or use an existing one). Cloud Console If you didn’t do it already, customize the . OAuth Consent Screen In the project context, navigate . APIs & Services | Credentials Then, press the button in the upper menu bar. + CREATE CREDENTIALS Select in the scrolling menu. OAuth Client Id Fill in the fields: Application type: Web application Name: whatever you want Authorized redirect URIs: , , <URL>/callback e.g. http://localhost:9080/callback should be the URL of the web application. Likewise, should match the plugin configuration above. URL /callback openid-connect Note that Google doesn't allow relative URLs, so if you need to reuse the application in different environments, you need to add the URL of each environment. Click the button. Create In the Docker Compose configuration above, use the Client ID and Client Secret as and . I wrote them down as environment variables in a file. OIDC_CLIENTID OIDC_SECRET .env The last missing variable is : it's . If you navigate to , you'll see all data required by OAuth 2.0 (and more). OIDC_ISSUER accounts.google.com https://accounts.google.com/.well-known/openid-configuration At this point, we can start our setup with . When we navigate to , the browser redirects us to the Google authentication page. docker compose up http://localhost:9080/ Since I'm already authenticated, I can choose my ID - and I need one bound to the organization of the project I created above. Then, I can freely access the resource. Configuring Azure for OIDC My colleague Bobur has already you need to do to configure Azure for OIDC. described everything We only need to change the OIDC parameters: OIDC_CLIENTID OIDC_SECRET : on Azure, it should look something like OIDC_ISSUER login.microsoftonline.com/<TENANT_ID>/v2.0 If you restart Docker Compose with the new parameters, the root page is now protected by Azure login. Conclusion Externalizing your authentication process to a third party may be sensible, but you want to avoid binding your infrastructure to its proprietary process. OpenID Connect is an industry-standard that allows switching providers easily. Apache APISIX offers a plugin that integrates OIDC so that you can protect your applications with the latter. There’s no reason not to use it, as all dedicated identity providers, such as Okta and Keycloak, are OIDC-compatible. The complete source code for this post can be found on . GitHub To go further: OpenID Connect OpenID Connect Discovery 1.0 specification Apache APISIX OIDC plugin API Security with OIDC by using Apache APISIX and Microsoft Azure AD Use Keycloak with API Gateway to secure APIs How to Use Apache APISIX Auth With Okta Originally published at on March 5th, 2023 A Java Geek