Authorization Code Grant
Authenticate third-party integrations requiring customer consent
The Authorization Code flow is the standard OAuth 2.0 flow for third-party applications that need to access the API on behalf of customers (RFC 6749 §4.1).
This flow is ideal when you need customer consent to access their data, such as when allowing a third-party Home Energy Management System (HEMS) to retrieve price information for a customer’s subscription. The flow ensures that the customer explicitly authenticates with Nomos and grants authorization to your application to access their data. Here’s how it works:
Keep your client_secret
secure and never expose it in client-side code.
Store it securely on your backend server and only use it there to exchange
authorization codes and refresh tokens for access tokens.
Get your credentials
Contact support@nomos.energy to obtain your client_id
and client_secret
. You’ll also need to configure your authorized redirect URIs.
Redirect to authorization
Direct customers to our authorization endpoint where they will first authenticate with their Nomos credentials and then consent to your application accessing their data:
The customer will first log in to their Nomos account if not already authenticated. After authentication, they will be shown a consent screen explaining what data your application is requesting access to.
PKCE (Proof Key for Code Exchange) is optional for the Authorization Code flow. If you decide to use it, you have to include both of these additional parameters:
code_challenge
: A code challenge derived from your code verifiercode_challenge_method
: Either “S256” (recommended) or “plain”
Handle the callback
After the customer authenticates and approves your application, we’ll redirect them back to your redirect_uri
with an authorization code:
This code is short-lived (valid for 10 minutes) and can only be used once to obtain access tokens.
Exchange for tokens
Exchange the authorization code for access and refresh tokens by making a request from your backend server:
The response will include an access token (valid for 60 minutes) and a refresh token:
When using PKCE, you must include the code_verifier
in the token request. The code verifier must:
- Be between 43 and 128 characters long
- Only contain alphanumeric characters and ’-’, ’.’, ’_’, ’~’
- Match the code challenge method used in the authorization request
Make authenticated requests
Include the access token in the Authorization header of your API requests:
Refresh expired tokens
When the access token expires, use the refresh token to obtain a new one:
PKCE Implementation Details
PKCE (Proof Key for Code Exchange) is a security extension to the OAuth 2.0 Authorization Code flow that prevents authorization code interception attacks. It is defined in RFC 7636. Here’s how to implement it:
-
Generate a Code Verifier:
- Create a random string between 43 and 128 characters
- Use only alphanumeric characters and ’-’, ’.’, ’_’, ’~’
- Store this securely in your application
-
Create a Code Challenge:
- If using
code_challenge_method="S256"
(recommended):- Hash the code verifier with SHA-256
- Base64url encode the hash
- If using
code_challenge_method="plain"
:- Use the code verifier directly as the challenge
- If using
-
Include in Authorization Request:
- Add
code_challenge
andcode_challenge_method
to the authorization URL - Keep the code verifier secure until the token exchange
- Add
-
Token Exchange:
- Include the original code verifier in the token request
- The server will validate that the verifier matches the challenge
We strongly recommend using the S256 code challenge method as it provides better security than the plain method.