Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

All services require a valid token from the IdP when called.

All services require TLS (version 1.2 or higher) for transport security.

In line with industry best practices the HIMSA IdP does not allow IFRAME based usage for any kind of user interactive authentication. An X-FRAME-OPTIONS HTTP header is always returned with the value ‘SameOrigin’.

...

Noah ES contains an Identity Provider that supports OAuth 2.0 and OpenId Connect. The Identity Provider (IdP) is used for Authentication.All services

require a valid token from the IdP when calledThe flow below applies to user interactive apps. For service apps / machine-to-machine client type the simplified Client Credentials flow is used.

1. Request

Parameters that must be supplied:

  • URI and port number

    • QA environment: idp.qa.eu.noah-es.com:443

    • EU Production: idp.eu.noah-es.com:443

    • US Production: idp.us.noah-es.com:443

  • ClientId: Supplied by HIMSA

  • Client secret: Supplied by HIMSA if required

  • Scope: openid

    offline_access

    profile noah.cloud.app.api

    • If relevant for your app and app registration allows: offline_access

  • Flow: Authorization Code + PKCE

  • RedirectURI: IdP will redirect the client to this after successful authentication, with tokens for accessing the API. You must inform HIMSA about this, because we need to whitelist it

  • Extra options

    • culture-lcid: Culture LCID code for localizing the website

...

When the client is redirected to the RedirectURI, the body in the response will contain:

  • auth_code: Must be exchanged afterwards for an access token

  • Id token

    • tenantid claim: The tenantId that the user selected

  • RefreshToken: Must be exchanged afterward for an access token. If using HIMSA's .NET Client this step is automated

...

    • “region” claim: We suggest that you use this to redirect the user to a hosted version of your web based app located in the same location as the account that the user selected (e.g. redirect from app.company.com to app-eu.company.com). Especially important for Noah ES accounts, to avoid processing e.g. EU patient data in your data center outside the EU

3. Exchange auth_code for an access token

Note: This is done automatically if you are using HIMSA's .NET Client.

Note

Access and refresh tokens may vary greatly in length. Make no assumptions about the contents. It can change at any point in time

4. Connecting to API

  • URI and port number
  • QA environment: api.qa.eu.noah-es.com:443
  • EU Production: api.eu.noah-es.com:443
  • US Production: api.us.noah-es.com:443

    We suggest that you use the URI returned as claim “api” in the id token, especially if using the global IdP endpoint that allows the user to select any account from any of our regions

  • HIMSA's .NET Client:

    • Use

      Either use the constructor that takes

      the

      an access token or a refresh token as input

Logging off

In case a user only set up 1 account and that account is of type single sign-on, logging off will redirect the user directly to the login page. In that case it will not be possible to set up a different account.

...

5. Renewal of access token

Note: This is done automatically if you are using HIMSA's .NET Client.

Lifetime of access tokens and refresh tokens varies depending on the client type and app type.

We never issue refresh tokens for service-apps/machine-to-machine apps. For other app types, it is possible to submit a support request for HIMSA to allow the use of refresh tokens for a specific app: https://himsanoah.atlassian.net/servicedesk/customer/portal/1/group/1/create/15