Log in an employee¶
Availability
This functionality is only available in the Google Cloud Platform environments.
This how-to guides you through the steps required to ensure that only employees authenticated with Entra ID can access your application.
Prerequisites¶
- Your application is exposed to the appropriate audience.
Configure your application¶
Enable the login proxy for Entra ID in your application configuration:
See the NAIS application reference for the complete specifications with all possible options.
Grant access to users¶
By default, no users have access to your application. You must explicitly grant access to either specific groups, all users, or both.
Groups¶
The following configuration only grants users that are direct members of the specified groups access to your application:
spec:
azure:
application:
enabled: true
allowAllUsers: false
claims:
groups:
- id: "<group identifier>"
Warning
Invalid group identifiers are skipped and will not be granted access to your application. Ensure that they are correct and exist in Entra ID.
All users¶
The following configuration grants all users access your application:
Now that your application is configured, you will need to handle inbound requests in your application code.
Handle inbound requests¶
As long as the employee is authenticated, the Authorization
header includes their access_token
as a Bearer token.
Your application is responsible for verifying that this token is present and valid. To do so, follow these steps:
Handle missing or empty Authorization
header¶
If the Authorization
header is missing or empty, the employee is unauthenticated.
Return an appropriate HTTP status code to the frontend, and redirect the employee's user agent to the login endpoint:
Validate token in Authorization
header¶
If the Authorization
header is present, validate the token.
If invalid, redirect the employee to the login endpoint:
Recommended JavaScript Library
See https://github.com/navikt/oasis that helps with token validation and exchange in JavaScript applications.
To validate the token, start by validating the signature and standard time-related claims. Additionally, perform the following validations:
Issuer Validation
Validate that the iss
claim has a value that is equal to either:
- the
AZURE_OPENID_CONFIG_ISSUER
environment variable, or - the
issuer
property from the metadata discovery document. The document is found at the endpoint pointed to by theAZURE_APP_WELL_KNOWN_URL
environment variable.
Audience Validation
Validate that the aud
claim is equal to the AZURE_APP_CLIENT_ID
environment variable.
Signature Validation
Validate that the token is signed with a public key published at the JWKS endpoint. This endpoint URI can be found in one of two ways:
- the
AZURE_OPENID_CONFIG_JWKS_URI
environment variable, or - the
jwks_uri
property from the metadata discovery document. The document is found at the endpoint pointed to by theAZURE_APP_WELL_KNOWN_URL
environment variable.
Claims Validation
Other claims may be present in the token. Validation of these claims is optional.
Next steps¶
The employee is now authenticated and can access your application.
However, the subject token found in the Authorization
header is only valid for your application.
To consume other APIs on behalf of the employee, exchange the token for a new token that targets a specific API.
Related pages¶
Learn how to consume other APIs on behalf of a employee