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:
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 (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 Code Challenge:
code_challenge_method="S256"
(recommended):
code_challenge_method="plain"
:
Include in Authorization Request:
code_challenge
and code_challenge_method
to the authorization URLToken Exchange:
We strongly recommend using the S256 code challenge method as it provides better security than the plain method.
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:
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 (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 Code Challenge:
code_challenge_method="S256"
(recommended):
code_challenge_method="plain"
:
Include in Authorization Request:
code_challenge
and code_challenge_method
to the authorization URLToken Exchange:
We strongly recommend using the S256 code challenge method as it provides better security than the plain method.