Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

Client to the ehealth infrastructure should implement an OpenID Connect "code flow" in order to login and get a set of tokens. 

Clients must be created in the login server and assigned a name.

Clients can be either confidential (like a server application) or public (like an app or a web application). Confidential clients authenticate themselves with a password. Public client must use PKCE (pronounced "pixi"). Explanations can be found many places, for instance here.

The loginserver of the infrastructure will delegate parts of the login to other servers, but that is transparent for the client (provided the login is handled by a generic browser window that can handle redirects).

Employee logins

For employees it is expected that the total login flow will look somewhat like this. Details can vary depending on the organization of the user (region, municipality or service/support/logistics organization).


Citizen logins (first time)

For citizens, a similar login flow could look like this:


Authorization Server

Unfortunately we don't have the right DNS names for the environments just yet.

But for now an Authorization Server for the inttest environment is available. Its endpoints is described in the contents of this URL: http://a90801479291d11e9865602ac812c206-157159182.eu-west-1.elb.amazonaws.com/auth/realms/inttest/.well-known/openid-configuration



  • No labels