Log in a citizenΒΆ
This how-to guides you through the steps required to ensure that only citizens authenticated with ID-porten can access your application.
PrerequisitesΒΆ
- Your application is exposed to the appropriate audience.
Configure your applicationΒΆ
Enable the login proxy for ID-porten in your application configuration:
Login proxy is only available in GCP
Login proxy is only available in GCP clusters, and will not work in on-prem clusters.
See the NAIS application reference for the complete specifications with all possible options.
Now that your application is configured, you will need to handle inbound requests in your application code.
Handle inbound requestsΒΆ
As long as the citizen 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 citizen is unauthenticated.
Return an appropriate HTTP status code to the frontend, and redirect the citizen's user agent to the login endpoint:
Validate token in Authorization
headerΒΆ
If the Authorization
header is present, validate the JWT Bearer token within.
If invalid, redirect the citizen to the login endpoint:
To validate a token, you can either:
- validate tokens with Texas, or
- validate JWTs manually in your application
Validate with TexasΒΆ
Texas is not enabled by default
See the Texas documentation for more information.
Send a HTTP POST request to the endpoint found in the NAIS_TOKEN_INTROSPECTION_ENDPOINT
environment variable.
The request must have a Content-Type
header set to either:
application/json
orapplication/x-www-form-urlencoded
The body of the request should contain the following parameters:
Parameter | Example Value | Description |
---|---|---|
identity_provider |
idporten |
Always idporten . |
token |
eyJra... |
The access token you wish to validate. |
The response is always a HTTP 200 OK response with a JSON body.
It always contains the active
field, which is a boolean value that indicates whether the token is valid or not.
Success responseΒΆ
If the token is valid, the response will also contain all the token's claims:
Texas validates the standard claims. Other claims are not validated. Your application must validate these claims according to your own requirements.
Error responseΒΆ
If the token is invalid, the only additional field in the response is the error
field:
The error
field contains a human-readable error message that describes why the token is invalid.
Validate JWT manuallyΒΆ
Validating a JWT involves a number of steps. These steps are outlined and described below in a language- and framework-agnostic way.
Libraries for token validation
We recommend using a library in your language of choice to handle all the validation steps described below. Here are some recommended libraries:
- navikt/oasis (JavaScript)
- navikt/token-support (Java / Kotlin)
Validation is also supported by many popular frameworks:
- Ktor (Kotlin)
- Spring Security (Java / Kotlin)
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
IDPORTEN_ISSUER
environment variable, or - the
issuer
property from the metadata discovery document. The document is found at the endpoint pointed to by theIDPORTEN_WELL_KNOWN_URL
environment variable.
Audience Validation
Validate that the aud
claim is equal to the IDPORTEN_AUDIENCE
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
IDPORTEN_JWKS_URI
environment variable, or - the
jwks_uri
property from the metadata discovery document. The document is found at the endpoint pointed to by theIDPORTEN_WELL_KNOWN_URL
environment variable.
Claims Validation
Other claims may be present in the token. Validation of these claims is optional.
Next stepsΒΆ
The citizen 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 citizen, exchange the token for a new token that targets a specific API.
Related pagesΒΆ
Learn how to consume other APIs on behalf of a citizen