How does OAuth2 work for microservices?

Key takeaways:

  • Securing microservices requires robust user authentication and authorization to prevent unauthorized access, complicating the management of credentials across services.

  • OAuth 2.0 facilitates permission granting between applications, enabling access to user resources across multiple microservices without direct identity verification.

  • Users log in through a centralized service to obtain an access token, which is then used by all microservices to authorize resource access, streamlining user interactions.

  • Each microservice validates the access token with the OAuth server, allowing seamless and secure interactions without repeated logins.

We live in a world dominated by microservices, through which we create, update, scale, and deploy applications easily. However, securing these microservices has become more challenging with the rise of this architecture. We must determine how to protect our services and stop unauthorized users from accessing protected resources. The solution lies in using user authentication and authorization. Authentication requires checking the user's access with the help of credentials. Then for authorization, a third-party application gains access to an account by providing the necessary user credentials.

OAuth 2.0 with microservices

OAuth 2.0, also known as Open Authorization, allows websites and apps on one host to gain permission to access resources from another host. It's widely used for securing microservices. OAuth 2.0 provides access to user data and remote APIs, unlike verifying identity. Microservices involve breaking down a monolithic application into more minor, standalone services that operate in separate processes. Each service manages a specific function and can be developed, deployed, and scaled independently. This approach enhances parallelism and boosts team productivity by allowing independent handling of different aspects of the overall functionality.

However, implementing OAuth 2.0 for microservices poses several challenges. This article is dedicated to a detailed exploration of these challenges, aiming to provide practical insights into addressing them.

Deploying microservices may be straightforward, but testing, verifying, and rolling back these services is complex due to their interdependencies with upstream and downstream components.

Dependent microservices (MS)
Dependent microservices (MS)

Challenge

Consider an e-commerce web app with some modules like "inventory management," "shopping cart," and "payment," each relying on distinct microservices. User authentication is essential to secure these modules from unauthorized access when interacting with microservices. However, requiring users to login whenever they access a microservice is impractical.

The challenge lies in enabling seamless access to resources across various microservices while users interact with a centralized login service, necessitating the sharing of credentials across these individual microservices without user awareness.

Solution

An access token is the solution to this problem. Let's discuss an access token and how we can achieve it. So, take the above web application as a client (web application or mobile application). 

  1. The user login using the client.

  2. The client has an ID and a client secret from the authorization server.

  3. The client requests authorization from the authorization server by generating a request.

  4. The authorization server verifies the identity of the client.

  5. The authorization server replies by sending an access encrypted token for the user and client.

  6. If the client has an access token, it will put it in the header and ask the resource server for the protected resource. And finally, the client will get the protected data.

  7. Now, this token is shared between various microservices. Each microservice validates the ticket with the authentication server (OAuth server) to allow access to protected resources. 

User login from client
User login from client
1 of 5

Note: If the authorization server provides an authorization code, it can be swapped for an access token.

Coding example

We code a dummy example, where we set for a Flask application acting as an OAuth 2.0 provider. While the code itself won't produce visible output when executed, it establishes the structure and behavior of the OAuth provider. Here, we create a client and two users inside the OAuth2 provider; some required values are set for the client and users.

from flask import Flask
from flask_oauthlib.provider import OAuth2Provider
# Create a Flask application
app = Flask(__name__)
# Set a secret key for session management
app.secret_key = 'random_secret_key'
# Create an instance of the OAuth2Provider and associate it with the Flask app
oauth = OAuth2Provider(app)
# Simulated client and user data
clients = {
    'dummy_client': {
        'secret': 'dummy_secret',
        'redirect_uris': ['http://localhost:5000/callback'],
        'default_scopes': ['email']
    }
}
users = {
    'user1': {'password': 'password1'},
    'user2': {'password': 'password2'}
}
# Define a function to load a client based on the provided client_id
@oauth.clientgetter
def load_client(client_id):
    return clients.get(client_id)
# Define a function to load a grant based on the provided client_id and code
@oauth.grantgetter
def load_grant(client_id, code):
    # This is a simplified example; in a real application, you would store and retrieve grants from a database.
    return {'client_id': client_id, 'code': code, 'redirect_uri': clients[client_id]['redirect_uris'][0]}
# Define a function to save a grant for a given client_id, code, and request
@oauth.grantsetter
def save_grant(client_id, code, request, *args, **kwargs):
    # This is a simplified example; in a real application, you would store grants in a database.
    return {'client_id': client_id, 'code': code, 'redirect_uri': request.redirect_uri}
# Define a function to get a user based on the provided username and password
@oauth.usergetter
def get_user(username, password, *args, **kwargs):
    if username in users and password == users[username]['password']:
        return {'id': username}
# Run the application in debug mode if executed as the main module
if __name__ == '__main__':
    app.run(debug=True)

Code explanation

  1. Line 1–5: The code imports the necessary modules, including Flask for creating the web application and Flask-OAuthlib for OAuth 2.0 implementation.

  2. Line 7–9: Creates a Flask application instance and sets a secret key for session management.

  3. Line 11: Initializes an instance of the OAuth2Provider and associates it with the Flask app.

  4. Line 14–21: Simulated data for registered clients with details such as client ID, secret key, redirect URIs, and default scopes.

  5. Line 23–27: Simulated data for registered users with usernames and passwords.

  6. Line 29–30: Defines a function (load_client) to retrieve client information based on the provided client ID.

  7. Line 34–35: Defines a function (load_grant) to recover grant information on the provided client ID and code.

  8. Line 40–42: Defines a function (save_grant) to save grant information for a client ID, code, and request.

  9. Line 46–48: Defines a function (get_user) to authenticate users based on the provided username and password.

  10. Line 66–68: Checks if the script is executed as the main module and runs the Flask application in debug mode if valid.

This code builds a secure OAuth 2.0 provider within a Flask application, allowing integration with third-party applications while ensuring user authentication and authorization.

Microservices creation and authentication

Below is an example of how three microservices might interact using access tokens issued by the OAuth server created in the previous code. 

from flask import Flask, jsonify, request
from flask_oauthlib.provider import OAuth2Provider
# Assuming the OAuth provider code is in a separate module
from oauth_provider import app as oauth_app, users as oauth_users
# Creating three microservices
app_service1 = Flask(__name__)
app_service2 = Flask(__name__)
app_service3 = Flask(__name__)
# Dummy secret keys for microservices (in a real scenario, these should be securely stored)
app_service1.secret_key = 'secret_key_service1'
app_service2.secret_key = 'secret_key_service2'
app_service3.secret_key = 'secret_key_service3'
# Using the same OAuth provider instance across microservices
oauth_service1 = OAuth2Provider(app_service1)
oauth_service2 = OAuth2Provider(app_service2)
oauth_service3 = OAuth2Provider(app_service3)
# Simulating user access data (shared among microservices)
user_access_data = {}
# Function to validate the access token with the OAuth provider
def validate_access_token(access_token):
    # In a real-world scenario, you would make an HTTP request to the OAuth provider's /tokeninfo endpoint
    # Here, we simulate it by checking if the access token exists in the user access data
    return access_token in user_access_data
# Microservice 1 route
@app_service1.route('/resource_provider1')
def resource1():
    access_token = request.headers.get('Authorization', '').split('Bearer ')[-1]
    if not validate_access_token(access_token):
        return jsonify({'error': 'Unauthorized'}), 401
    return jsonify({'data': 'This is Resource provider 1 from Microservice 1'})
# Microservice 2 route
@app_service2.route('/resource_provider2')
def resource2():
    access_token = request.headers.get('Authorization', '').split('Bearer ')[-1]
    if not validate_access_token(access_token):
        return jsonify({'error': 'Unauthorized'}), 401
    return jsonify({'data': 'This is Resource provider 2 from Microservice 2'})
# Microservice 3 route
@app_service3.route('/resource_provider3')
def resource3():
    access_token = request.headers.get('Authorization', '').split('Bearer ')[-1]
    if not validate_access_token(access_token):
        return jsonify({'error': 'Unauthorized'}), 401
    return jsonify({'data': 'This is Resource provider 3 from Microservice 3'})
# Example: Simulating the user accessing the OAuth server to get an access token
@app_service1.route('/get_access_token')
def get_access_token():
    # Simulate the user authentication process and obtaining an access token from the OAuth server
    # In a real scenario, this would involve redirecting the user to the OAuth server's authorization endpoint
    # and handling the OAuth flow to obtain an access token.
    user_credentials = {'username': 'user1', 'password': 'password1'}
    response = app_service1.test_client().post('/oauth/token', data={
        'grant_type': 'password',
        'username': user_credentials['username'],
        'password': user_credentials['password'],
        'client_id': 'dummy_client',
        'client_secret': 'dummy_secret',
    })
    access_token = response.json.get('access_token')
    # Save the access token in the user access data
    user_access_data[access_token] = user_credentials['username']
    return jsonify({'access_token': access_token})
if __name__ == '__main__':
    # Run each microservice on a different port
    app_service1.run(port=5001, debug=True)
    app_service2.run(port=5002, debug=True)
    app_service3.run(port=5003, debug=True)

Please note that this is a simplified example, and in a real-world scenario, you'd need to implement proper security measures and error handling.

Code explanation

  1. Lines 2–4: Import necessary modules.

  2. Lines 6–8: Create three Flask microservice instances (app_service1, app_service2, app_service3).

  3. Lines 10–12: Set secret keys for session management for each microservice.

  4. Lines 14–16: Use the same OAuth provider instance for each microservice.

  5. Lines 18–20: Simulate user access data shared among microservices.

  6. Lines 22–26: Define a function (validate_access_token) to simulate access token validation.

  7. Lines 28–37: Define routes for Microservices 1, 2, and 3. Each course checks the validity of the access token before providing access to resources.

  8. Lines 39–52: Simulate a user accessing the OAuth server to obtain an access token.

  9. Lines 55–59: Run each microservice on different ports when the script is executed as the main module.

This code sets up three microservices that share an OAuth provider for user authentication and access token validation. Each microservice has its routes (resource_provider1, resource_provider2, resource_provider3) that require a valid access token for access. The simulated access token is obtained by a user accessing the OAuth server (get_access_token route).

Wrap up

This article teaches a bit about OAuth 2.0 workflow with microservices. It also discussed code to understand how to add clients and users to the OAuth 2.0 server and create microservices that share an OAuth provider for user authentication in Python.

Note: To learn more about OAuth 2.0, see Educative’s course Authorization with OAuth 2.0 in Python. Educative’s platform lets you write and run code inside the browser without installing software.

Quiz

1

In a microservices architecture, how does OAuth 2.0 enhance security when a client application needs to access multiple services on behalf of a user?

A)

Providing API key

B)

Providing access token

C)

Redirecting users to services directly

Question 1 of 20 attempted

Free Resources

Copyright ©2025 Educative, Inc. All rights reserved