Versions Compared

Key

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

...

  • shall only establish connections to servers, including HelseID, using TLS. All TLS connections shall be set up using TLS version 1.2 or later, and follow RFC 7525.

  • shall use authorization code grantAuthorization Code flow, as described by IETF in OAuth 2.0 and by OIDF in OpenID Connect for interactive sessions (end-user sessions)., OR

  • Shall shall use the Client Credentials flow as described in RFC 6749.

  • shall be confidential clients, meaning that the client secrets used to authenticate the clients are known to HelseID prior to the authentication.

  • shall pass request parameters as JWT as described by OIDF in OpenID Connect, and as detailed by HelseID.

  • shall support client authentication using eitherusin:

    • private_key_jwt”, as described by OpenID Connect for interactive sessions.

    • Client Assertions as described by RFC 7521 and RFC 7523.

    • Mutual-TLS for OAuth Client Authentication as described by RFC 8705.

    • The requirements for client authentication are further detailed by HelseID

  • shall support sender-constrained tokens using either

    Mutual-TLS for OAuth Certificate-Bound Access Tokens mTLS for OAuth as described by RFC 8705.

    • Demonstrating Proof-of-Possession at the Application Layer (DPoP) as described by draft-ietf-oauth-dpop. At the moment this specification has a draft status, so it is liable to change.

  • shall use PKCE, as defined by IETF in RFC 76936 - Proof Key for Code Exchange, to mitigate against code interception and other attacks.

  • shall send access tokens in http authorization headers, as described by RFC 6750.

  • shall use the “authorization_details” structure, as defined by IETF in the specification Rich Authorization Requests, to convey fine grained authorization requirements to HelseID.

    • These requirements are further detailed by HelseID.

  • shall check the the validity of the “iss” parameter in the authorization response to prevent mix-up attacks.

  • shall implement protection against XSS and CSRF attacks. Please refer to external sources as OWASP for details about how to test and secure a client.

  • shall not expose to open redirectors where the client is vulnerable to malicious redirections . Please refer to external sources to find descriptions of mitigations to these types of attacks.

    • the client shall protect against attacks via HTTP Header

    • the client shall protect against attacks via Javascript (e.g. XSS attacks)

...

OAuth 2.0 for Native Apps: https://tools.ietf.org/html/rfc8252

OAuth 2.0 mTLS: https://www.rfc-editor.org/rfc/rfc8705.html

The OAuth 2.0 Authorization Framework - Bearer Token usage: https://tools.ietf.org/html/rfc6750

...

OpenID Connect: https://openid.net/specs/openid-connect-core-1_0.html

FAPI 2.0: https://openid.bitbucket.orgio/openidfapi/fapi/src/master/FAPI_-2_0_Baseline_Profile.md-security-profile

OAuth 2.1: https://tools.ietf.org/html/draft-ietf-oauth-v2-1-00

OAuth DPoP: https://toolswww.ietf.org/archive/htmlid/draft-ietf-oauth-dpop-0213