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 9 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, and the URL's used to redirect back to the client must be whitelisted.

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 and 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).

Client types

Clients come in two flavors. Emplyee- and citizen clients. Each type uses it's own login flow and realm which results in two authorization url's (please see the section Login for further information).

As a result: If clients (and server applications) handles both employee and citizen users, then token validation must be able to handle multiple certificate url's.
Example of certificate url's for the inttest environment:

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

Current active environments:

Employee:

Base url: https://saml.${environment}.ehealth.sundhed.dk/auth/realms/ehealth

Citizen:

Base url: https://saml.${environment}.ehealth.sundhed.dk/auth/realms/nemlogin

Client Adapters

Keycloak has an extensive set of client adapters (libraries) for usage on various platforms and programming languages:

Example authentication

If, for some reason, you can't use a keycloak client adapter - here is an example URL for an authentication request using HTTP GET, written in a readable format. It should be sent as a single line without spaces or newlines.

Authentication request
 http://saml.inttest.ehealth.sundhed.dk/auth/realms/ehealth/protocol/openid-connect/auth?
  response_type=code&
  client_id=<client_id>&
  redirect_uri=<redirect_uri>&
  scope=openid+profile&
  state=<state>&
  nonce=<nonce>&
  code_challenge=<challenge>&
  code_challenge_method=S256

The parameters have the following meaning:

  • response_type=code – indicates that your server expects to receive an authorization code
  • client_id= – A client ID that is registered on the Authorization Server
  • redirect_uri= – Indicates the URL to return the user to after authorization is complete, such as org.example.app://redirect or a tradition URL for a webapp https://app.example.org/redirect.
  • state=1234zyx – A random string generated by your application, which you’ll verify later
  • code_challenge=XXXXXXXXX – The code challenge generated as previously described
  • code_challenge_method=S256 – either plain or S256, depending on whether the challenge is the plain verifier string or the SHA256 hash of the string. If this parameter is omitted, the server will assume plain.

When the authentication is complete, the browser is redirected back to the given "redirect_uri" (which must be whitelisted in the Authorization Server) including a "code" as a request parameter. This code must be used when calling the token endpoint afterwards.

Example token exchange

Here is an example of the following POST request to obtain a context aware access token

Authorization code exchange
POST /auth/realms/ehealth/protocol/openid-connect/token HTTP/1.1
Content-Type: application/x-www-form-urlencoded

  grant_type=refresh_token&
  refresh_token=<refresh_token>&
  client_id=<client_id>&
  client_secret=<client_secret>

NOTE: The post parameters is to be expanded at a later time to include careteam-id, patient-id, etc.



  • No labels