Hjem > idporten > oidc

Changes in the new ID-porten in 2022-2023

Background

“We are making comprehensive changes in the core of ID-porten to make it more modern, robust and secure for the future. One of the main objectives for this project is to minimize the impact on our customers. There is aproject page on Samarbeidsportalen, this page contains the status for the project and a timeline for the migration.

We know the new solution will not be 100% downward compatible, so we have created this page in order to highlight the coming changes. The changes will mainly effect propriatary mechanisms created by us, as well as any custom usage that deviates from the standard Oauth protocol. We started to use Oauth in an early draft-phase and we can see that standard libraries and applications are not using the mechanisms in the way we tought they would be used.

The current agreement with our vendor TietoEvry expires in Q3 2023. On the new agreement, we wish to run all services on the new platform only. The new architechture will be based on the Kubernetes platform, and we will use SaaS services if needed. The “heart” of the new ID-porten will be based on a modern Oauth2/OIDC-authorization server from Connect2Id.

Migration plan

Have a look at the status-page for the new ID-porten on Samarbeidsporten for a detailed timeline. When the changes are coming to our production enviroment, we will post a message on our Statuspage.

The migration will be divided into 4 main stages.

Stage	Date	Description
1: Pilot	March 2023	The production enviroment for the new Nye ID-porten is ready for selected services. No SSO to the old platform
2: Normal operation	May 2023	The new OIDC solution is ready with full functionality and performance.
3: Moving of OIDC	21. nov 2023	The old OIDC-provider will be routed to the new ID-porten instance. 90% of traffic will the go through the new solution. Existing SAML-integrations will loose SSO temporarily
4: Moving of SAML	Jan 2024	All SAML integrations will be seemlessly moved from the old ID-porten to the new SAML proxy. SAML-integrations will regain SSO towards OIDC-based integrations. between old and new platform is ready.
4: Shutdown	23. feb 2024	The old OIDC-issuer is turned off.

When should i migrate ?

If you are depending on SSO to other services, like Altinn, you need to wait until after september 2023.

If not, we recommend you to migrate as soon as possible starting from the end of march. Critical national services should migrate after the pilot period. Digdir will make direct contact with important/critical services.

How do i migrate ?

This depends on your current integration.

A: Customer with existing OIDC client

In most cases, these are the steps to follow:

Open the outbound firewall to the new IP-adress.
Change the issuer-URL to point to the new URL: https://idporten.no .
- Some IAM-products will download the updated metadata and trust our new certificate automatically.
If step 2 did not happen automatically, you need to manually configure the new endpoints from our metadata and trust our new signing certificate.
Configure your integration to use PKCE
You will be able to re-use your existing client_id
You will be able to re-use your existing client_secret as well as your existing business certificate / key

B: Customer with SAML integration

If you want to stay on SAML, you need to check if your SAML integration is compatible with the reduced functionality of the new SAML proxy. This could be checked when the test-enviroment is ready. You will also need to open the outgoing firewall for the new IP-adress.

We recommend all our customers to use OIDC. This would require setting up a new client and follow our integration steps..

Detailed changes to the protocol:

The new ID-porten is aiming to follow the Oauth2.1 specifications, unlike 2.0 which is used today. This is because we want to follow the updated security demands from 2.1 The standard flow for alle integrations will be OIDC and code flow with forced use of PKCE, state and nonce.

New issuer

The new ID-porten will run on a new domain with a new issuer value: iss=https://idporten.no/. Our signing certficate will also be changed. By providing a new issuer, we will make it possible for our customers to gradually migrate to our new solution at a suitable time.

However, this will make it a bit more complicated for API-owners that are using brukerstyrt datadeling. These API-owners will need to trust access_tokens from two issuers unless they coordinate the migration with their customers.

At the end of the migration period, the old issuer will be permanently shut down. Clients that are not migrated by this point will not work any longer.

New IP

The new ID-porten will run on a different IP-adress than today. All customers with outbound firewall must open the firewall to our new adress. The adress will be posted here when ready.

SSO

The new ID-porten will offer SSO between all integrations between SAML and OIDC.

Please note, in the pilot-stage and the start of the migration period there will be no SSO between the new and old ID-porten.

The new ID-porten will offer a SSO-free login. Customers will be able to configure their clients wether to allow SSO or not. This will be done through our self-service portal og API.

onbehalfof

onbehalfof is a custom-made mechanism in ID-porten to be used by vendors. This will still be available for OIDC and SAML.

New acr values

There are new values for authentication levels. The new values are idporten-loa-substantial and idporten-loa-high. They can be used by a client to request user authentication on a minimum level with the acr_values parameter. ID-porten will include the authentication level in the acr claim in the id_token.

“Old” ID-porten	“New” ID-porten	Description
	idporten-loa-low	As of now, there are no electronic IDs on the security level
Level3	idporten-loa-substantial	Equivalent of security level “substantial” in eIDAS. In ID-porten, MinID is currently the only eID on this security level
Level4	idporten-loa-high	Equivalent of security level “high” in eIDAS. ID-porten offers BankID, Buypass and Commfides on this security level

Forced use of PKCE, state and nonce.

All clients must use PKCE in addition to instance-uniquie state and nonce values. On todays solution, this is only required by public clients, and voluntarely yet higly recommended for confidential clients.

PKCE code challenge

PKCE code_challenge must not use padding.

state encoding

The state parameter will be URL encoded before it is returned to the client on authrization response and post logout redirect. This affects clients using HTML/JSON/som ekind of data structure as state value. The value should be URL decoded when recieved on these callbacks.

`sub` will be changed

The sub-value from the id_token will be changed. Even tough most of our customers primarily use the social security number in the pid-claim , there are some IAM-products that uses the sub-value. In some cases, the IAM-product creates lokal user-databases (e.g. Keycloak), and there is a risk of duplicates.

In the access_token, the sub will also get new values.

Changes to Single logout and revoking

Due to changes in the OIDC specifications regarding logout, some changes have been implemented:

The logout endpoint supports both GET and POST
if a client is registered with front channel logout uri it will receieve calls to this uri when it is the initiator of the logout request
it is important to add login.idporten.no / login.test.idporten.no as a legal frame-ancestors in the Content Security Policy

We are considering to change todays behavior and align it to the spec.

In todays solution, revoking the access_token/refresh_token will terminate the SSO session. Is this appropriate behavior?
Is it appropriate that logging out of a SSO-sessjon, also invalidates all tokens belonging to the clients within the session?
The spec requires a “do you really want to log out?” message in ID-porten in the logout process. Should we implement this?
How strict should the requirements be, in order to redirect the end-user browser to the stated post_logout_redirect_uri ?

More frequent redirect back to the client in case of errors

In the current OIDC solution, all error situations generates an error page in ID-porten and the login flow stops. In the new ID-porten, the end-user will more frequently be redirected back to the client along with an error description.

Removal of implicit flow support

In the latest recommendations from IETF, implicit flow is not recommended. In ID-porten, implicit is not allowed on new integrations, but is still available on existing clients. I new ID-porten, implicit will not be available for any clients. Clients using implicit today, must change their solution to using code flow with PKCE. On a longer term, we are also considering implementing support for DPop.

Claim at_hash revomed from the id_token

The claim at_hash will be removed from the id_token. at_hash is required in implicit flow. It is not needed in the authorization code flow.

Tightening in client authentication with private_key_jwt

JWT for the client_assertion-parameter must contain both sub and iss claims. The parameter client_id must be stated to the token-endpoint along with client_assertion. This is documentet in the current solution, but the validation will be more strict in the new solution.

New parameter in respons from authorization endpoint - `iss`

Response from the authorization endpoint will include iss which contains the value from the ID-porten issuer in that enviroment. This could be used to avoid “mix-up-attacks”. This is spesified in RFC 9207.

Client_id is required when using request_uri towards the authorization endpoint

When using PAR (pushed auhtorization request), both client_idand request_uri must be included when calling the authorization endpoint

Token introspection requires a special scope and client authentication

When using token introspection, the client must authenticate itself. Use the same client authentication method with the token endpoint and the token introspection endpoint. The client must be registered with the scope idporten:token.introspection. Ask the service desk for help.

SAML

The new ID-porten will only offer a very basic SAML-support, only to existing services. We will develop a simple SAML-to-OIDC-proxy which will be placed in front of the new OIDC-iusser.

The SAML proxy will support SAML Web Browser SSO 2.0 with Artifact Resolution binding. It will support only 1 AssertionConsumerURL and 1 combined signing- og encryption certificate.

Contact details (email/mobile) will no longer be included as part of the Assertion.

NameID values will change when we migrate. The actual value will be persistent, even if the SP asks for a transient value in the AuthnRequest.

Updating the SAML-metadata will not be available. When the metadata expires (e.g. when the certificate expires), we expect that our customers starts using OIDC instead of SAML.

SAML will be phased out completely.

Pseudonymization

Pseudonymization will be affected by the change of the sub parameter. (See above)

The no_pid scope will be deprecated, meaning that all customers must use opaque tokens or pseudonymized scopes.