Guidance on securely configuring authorization and authentication frameworks - ITSP.40.063

Effective date

This publication takes effect on July 13, 2026.

Revision history

  1. First release: July 13, 2026.

Overview

This publication identifies and describes authorization and authentication frameworks that organizations can implement to protect sensitive information. For Government of Canada (GC) departments and agencies, the guidance in this publication applies to UNCLASSIFIED, PROTECTED A, and PROTECTED B information. This guidance should be used in conjunction with Cryptographic Algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B Information (ITSP.40.111). The configurations in this publication comply with the cryptographic requirements in ITSP.40.111.

Your organization's ability to securely process user authorization and authentication is fundamental to the delivery of your programs and services. Using cryptographic security frameworks ensures the confidentiality, integrity and availability of information and helps protect against certain cyber intrusion threats.

Data confidentiality, integrity, and availability, stakeholder authentication and accountability, as well as non-repudiation are all benefits of properly configured authorization and authentication frameworks. You may need to use various frameworks to satisfy your organization's specific security requirements. You should select and implement each framework to ensure all requirements are met.

For more information on securely configuring authorization and authentication frameworks, contact the Cyber Centre.

Table of contents

1 Introduction

Organizations rely on information technology (IT) systems to achieve business objectives. These interconnected systems can be the targets of serious cyber attacks and other threats that jeopardize the confidentiality, integrity and availability of information assets. Compromised networks, systems or information can have adverse effects on business activities and may result in data breaches and financial loss.

This publication provides guidance on securely configuring authorization and authentication frameworks to protect sensitive information using cryptographic algorithms recommended by the Cyber Centre for the UNCLASSIFIED, PROTECTED A, and PROTECTED B levels. It complements the Treasury Board of Canada Secretariat (TBS) Guideline on Defining Authentication Requirements. Organizations are responsible for determining their security objectives and requirements as part of their risk management framework.

1.1 IT security risk management process

When implementing security protocols, practitioners should consider the IT security risk management activities described in Cyber security and privacy risk management: A lifecycle approach (ITSP.10.033). ITSP.10.033 addresses 2 levels of IT security risk management activities: departmental-level and information system-level activities. It also includes a catalogue of security controls (for example, standardized security requirements to protect the confidentiality, integrity and availability of IT assets).

Additionally, organizations should consider the following activity areas:

  • define
  • develop
  • allocate
  • monitor and assess
  • maintain and update

Read Organizational cyber security and privacy risk management activities (ITSP.10.036) for more information on these activities.

Departmental-level activities (or organizational-level activities for non-GC organizations) are included in departmental or organizational security programs to plan, manage, assess and improve the management of IT security risks.

Information system-level activities are included in an information system's lifecycle through the information system security implementation process (ISSIP). When implementing network security protocols, you should consider all the steps in the ISSIP. Read System lifecycle cyber security and privacy risk management activities (ITSP.10.037) for more details on information system security risk management.

1.2 General recommendations

For each framework listed in this publication, the recommendations are best considered as a whole package. Choosing to follow some recommendations and not others may result in security vulnerabilities.

When using a public key infrastructure (PKI) with any of these frameworks, you should follow the PKI guidance in Guidance on securely configuring network protocols (ITSP.40.062).

1.3 Post-quantum cryptography

Quantum computers threaten to break many of the public key cryptosystems that we currently use. In August 2024, the National Institute of Standards and Technology (NIST) published standards for post-quantum cryptography that are designed to be resistant to the advantages of future quantum computers. For additional information on these standards, read Cryptographic algorithms for UNCLASSIFIED, PROTECTED A, and PROTECTED B information (ITSP.40.111).

Once the standards for the various authorization and authentication frameworks are revised to include post-quantum cryptography, we expect to update this publication to include recommendations for post-quantum configurations.

In the meantime, the Cyber Centre recommends the following high-level steps:

  • Evaluate the sensitivity of your organization's information and determine its lifespan to identify information that may be at risk (for example, as part of on-going risk assessment processes)
  • Review your IT lifecycle management plan and budget for potentially significant software and hardware updates
  • Educate your workforce on the quantum threat

For more detailed information, read Preparing your organization for the quantum threat to cryptography (ITSAP.00.017).

Organizations should wait until the standards for using post-quantum cryptography in frameworks are finalized before revising configurations to protect information or systems.

Top of page 

2 OAuth and OpenID Connect

OAuth is an authorization protocol framework that leverages a third-party authorization server enabling an end user to authorize a client to access its resources. The OpenID Connect (OIDC) protocol can be used with OAuth to provide user authentication. The recommendations in this section apply to the use of both OAuth and OIDC, except when noted otherwise.

In OIDC, an OAuth client is referred to as a relying party and an OAuth authorization server is referred to as an OpenID provider or identity provider.

The Cyber Centre recommends the use of OAuth version 2.0, originally defined in the Internet Engineering Task Force (IETF) Request for Comments (RFC) 6749 The OAuth 2.0 Authorization Framework and in updates from subsequent RFCs according to guidance in this section.

When using OIDC, use the version as defined in OpenID Connect Core 1.0 incorporating errata set 2.

The Cyber Centre also recommends securing all OAuth and OIDC communication with Transport Layer Security (TLS) configured according to the Guidance on securely configuring network protocols (ITSP.40.062).

2.1 OAuth and OpenID Connect clients

OAuth defines 2 types of clients: public and confidential. The Cyber Centre recommends using the 'confidential' client type.

When making requests to the OAuth authorization server, your organization should use 1 of the following methods for client authentication:

  • client_secret_jwt
  • private_key_jwt
  • tls_client_auth (when only using OAuth)
  • self_signed_tls_client_auth (when only using OAuth)

When using either the "client_secret_jwt" or "private_key_jwt" authentication method, the authorization server's issuer identifier should be used as the value for the "aud" claim.

2.1.1 Client registration and server discovery

To register OAuth and OIDC clients, the Cyber Centre recommends using dynamic registration in accordance with the IETF RFC 7591 OAuth 2.0 Dynamic Client Registration Protocol, and with OpenID Connect Dynamic Client Registration 1.0 incorporating errata set 2 when registering OIDC clients. When these 2 specifications conflict, follow the guidance in RFC 7591.

During registration, the Cyber Centre recommends registering the following optional information with the authorization server:

  • all redirection uniform resource identifiers (URIs) the client may use in the authorization request; all URIs should be complete and use the 'https' scheme
  • the client's authentication method and associated signature algorithms that will be used at the authorization server's endpoints
  • the signature and encryption algorithms to be used by both parties throughout the protocol

Clients should register each redirection URI with only 1 authorization server.

The Cyber Centre recommends using the "jwks_uri" client parameter. Clients incapable of hosting public uniform resource locators (URLs) should use the "jwks" parameter.

In addition, the Cyber Centre recommends that authorization servers:

  • provide a way for clients to query and update the registration information
  • assign unique client IDs to different instances of the same software
  • assign unique client secrets to all registration requests, even those from the same software or software instance
  • provide lists of supported signature and encryption algorithms for each type of data being signed or encrypted
  • provide the location of the UserInfo endpoint (when using OIDC)

When using OIDC, use the OIDC discovery protocol as specified in OpenID Connect Discovery 1.0 incorporating errata set 2.

2.2 Digital signatures and encryption

OAuth and OIDC make extensive use of JavaScript Object Notation (JSON) Web Signatures (JWS) and JSON Web Encryptions (JWE).

Where a JWS is used within OAuth or OIDC, the Cyber Centre recommends using 1 of the following for the "alg" parameter:

  • PS256 (RSASSA-PSS using SHA-256 and MGF1 with SHA-256)
  • PS384 (RSASSA-PSS using SHA-384 and MGF1 with SHA-384)
  • PS512 (RSASSA-PSS using SHA-512 and MGF1 with SHA-512
  • ES256 (ECDSA using P-256 and SHA-256)
  • ES384 (ECDSA using P-384 and SHA-384)
  • ES512 (ECDSA using P-521 and SHA-512)
  • Ed25519 (EdDSA using Ed25519 curve)
  • Ed448 (EdDSA using Ed448 curve)

If none of the above are available, it is sufficient to use 1 of the following:

  • RS256 (RSASSA-PKCS1-v1_5 using SHA-256)
  • RS384 (RSASSA-PKCS1-v1_5 using SHA-384)
  • RS512 (RSASSA-PKCS1-v1_5 using SHA-512)

If it is necessary to use the "client_secret_jwt" authentication method, 1 of the following algorithms may be used for the JWS "alg" parameter when signing the client authentication JSON Web Token (JWT):

  • HS256 (HMAC using SHA-256)
  • HS384 (HMAC using SHA-384)
  • HS512 (HMAC using SHA-512)

Where a JWE is used within OAuth or OIDC, the Cyber Centre recommends using 1 of the following for the "alg" parameter:

  • RSA-OAEP-256 (RSAES OAEP using SHA-256 and MGF1 with SHA-256)
  • RSA-OAEP-384 (RSA-OAEP using SHA-384 and MGF1 with SHA-384)
  • RSA-OAEP-512 (RSA-OAEP using SHA-512 and MGF1 with SHA-512)
  • ECDH-ES (ECDH-ES using Concat KDF)
  • ECDH-ES+A128KW (ECDH-ES using Concat KDF and "A128KW" wrapping)
  • ECDH-ES+A192KW (ECDH-ES using Concat KDF and "A192KW" wrapping)
  • ECDH-ES+A256KW (ECDH-ES using Concat KDF and "A256KW" wrapping)

Where a JWE is used within OAuth or OIDC, the Cyber Centre recommends using 1 of the following for the "enc" parameter:

  • A128CBC-HS256 (AES_128_CBC_HMAC_SHA_256 authenticated encryption algorithm)
  • A192CBC-HS384 (AES_192_CBC_HMAC_SHA_384 authenticated encryption algorithm)
  • A256CBC-HS512 (AES_256_CBC_HMAC_SHA_512 authenticated encryption algorithm)
  • A128GCM (AES GCM using 128-bit key)
  • A192GCM (AES GCM using 192-bit key)
  • A256GCM (AES GCM using 256-bit key)
Top of page 

2.3 Authorization

The Cyber Centre recommends using the authorization code grant for OAuth and the authorization code flow for OIDC. When an OAuth client is requesting access to its own resources, the client credentials grant can be used instead.

Authorization codes should have a maximum lifetime of 60 seconds.

2.3.1 Authorization requests and responses

The Cyber Centre recommends using the "state" and "redirect_uri" parameters in authorization requests, and authorization servers should perform exact string matching of the "redirect_uri" against the URIs provided at registration. You should also use the "nonce" parameter when you use OIDC.

The Cyber Centre recommends using 1 of the following response modes:

  • form_post
  • jwt (encrypted)
  • jwt (encrypted)
  • jwt (either encrypted or unencrypted)

When using OAuth, you should use rich authorization requests, as defined in IETF RFC 9396 OAuth 2.0 Rich Authorization Requests and the Proof Key for Code Exchange (PKCE) extension defined in IETF RFC 7636 Proof Key for Code Exchange by OAuth Public Clients with "S256" as the code challenge method. Use of PKCE with OIDC is optional.

At least 1 of the "state", "nonce", and "code_challenge" parameters should be cryptographically bound to the user agent.

Authorization responses should contain the issuer identifier claim "iss" as defined in IETF RFC 9207 OAuth 2.0 Authorization Server Issue Identification or be encoded as defined in JWT Secured Authorization Response Mode for OAuth 2.0 (JARM).

2.3.2 Pushed authorization requests

The Cyber Centre recommends the use of pushed authorization requests, as defined in IETF RFC 9126 OAuth 2.0 Pushed Authorization Requests. Any URIs generated by the authorization server for use with pushed authorization requests should have a maximum lifetime of 60 seconds and be single use. Clients should not be allowed to use unregistered redirect URIs.

2.3.3 JWT-secured authorization request

The JWT-secured authorization request (JAR), as defined in IETF RFC 9101 The OAuth 2.0 Authorization Framework: JWT-Secured Authorization Request (JAR), may optionally be used. When JAR is used, the Cyber Centre recommends using the "request" parameter to send the request object to the authorization server. Request objects should be signed and the keys used should not be used for signing other JWTs. The request object may optionally be encrypted after signing. Additionally, request objects should be single-use and contain a unique "state" parameter. For OIDC, the request object should contain a unique "nonce" parameter. Authorization servers should verify the source of a request by verifying the JWS.

Top of page 

2.4 Tokens

2.4.1 Token exchange

The Token Exchange allows a client to obtain access and ID tokens. The client should include the redirection URI value in the token request and ensure that the value is the same as in the corresponding authorization request.

The authorization server should verify that an authorization code is only redeemed once. If there is an attempt to use it again, the authorization server should revoke all tokens issued for the authorization code.

2.4.2 Access tokens

Access tokens authorize a client to access a resource server on behalf of a user. The Cyber Centre recommends that implementations format access tokens as JWTs that are signed and optionally encrypted.

Access tokens should:

  • have a maximum lifetime of 3,600 seconds
  • be passed in the HTTP header
  • be associated to a single resource server

When using OAuth, the authorization details object should be included as a claim in the token.

The Cyber Centre recommends the use of sender-constrained resource access tokens using 1 of the following methods:

When mutual TLS is used, you should:

When demonstrating proof of possession (DPoP) is used, you should use a server-provided "DPoP nonce" and bind the authorization code to the DPoP key.

2.4.3 OpenID Connect ID tokens

This subsection only applies to OIDC.

An ID token contains claims asserting that the user has been authenticated. When an ID token and access token are issued together, the "at_hash" claim should be included in the ID token.

The Cyber Centre recommends that all ID tokens be signed and that ID tokens returned from an authorization endpoint be encrypted. ID tokens returned from a token endpoint may optionally be encrypted.

2.4.4 Refresh tokens

A refresh token permits a client to obtain a new access or ID token without reauthenticating the user. The Cyber Centre recommends formatting refresh tokens as signed JWTs which may optionally be encrypted.

In addition, refresh tokens should be:

  • revokable and have an expiration time
  • sender-constrained or one-time use
  • used with refresh token rotation

When using OIDC, if an ID token is being returned in a refresh response, this token should not contain the nonce that was in the original ID token.

2.5 OpenID Connect UserInfo endpoint

This subsection only applies to OIDC.

A UserInfo endpoint permits clients to retrieve claims about an authenticated user. UserInfo requests should use the HTTP "GET" method and send access tokens using the "authorization" header field.

The Cyber Centre also recommends that the UserInfo response be signed. The UserInfo response may optionally be encrypted after signing.

Top of page 

3 Grant Negotiation and Authorization Protocol

The Grant Negotiation and Authorization Protocol (GNAP) is specified in IETF RFC 9635 Grant Negotiation and Authorization Protocol (GNAP) and IETF RFC 9767 Grant Negotiation and Authorization Protocol Resource Server Connections. It defines a mechanism for a client software instance to make a request to an authorization server for delegated access to a user's resources on a resource server and/or subject information.

3.1 Client instance key

The client instance key is bound to the access token for a particular client instance and can be used by authorization servers to identify such an instance. Clients interacting with multiple authorization servers should use a different key for each server they interact with.

Clients should use 1 of the following key formats:

  • jwk
  • cert
  • cert#S256

When using the jwk format, use 1 of the following algorithms for the "alg" parameter:

  • RSA-OAEP-256 (RSAES OAEP using SHA-256 and MGF1 with SHA-256)
  • RSA-OAEP-384 (RSA-OAEP using SHA-384 and MGF1 with SHA-384)
  • RSA-OAEP-512 (RSA-OAEP using SHA-512 and MGF1 with SHA-512)
  • ECDH-ES (ECDH-ES using Concat KDF)
  • ECDH-ES+A128KW (ECDH-ES using Concat KDF and "A128KW" wrapping)
  • ECDH-ES+A192KW (ECDH-ES using Concat KDF and "A192KW" wrapping)
  • ECDH-ES+A256KW (ECDH-ES using Concat KDF and "A256KW" wrapping)
  • A128KW (AES Key Wrap using 128-bit key)
  • A192KW (AES Key Wrap using 192-bit key)
  • A256KW (AES Key Wrap using 256-bit key)
  • A128GCMKW (Key wrapping with AES GCM using 128-bit key)
  • A192GCMKW (Key wrapping with AES GCM using 192-bit key)
  • A256GCMKW (Key wrapping with AES GCM using 256-bit key)

The Cyber Centre further recommends using of 1 of the following proof formats, which are defined in RFC 9635:

  • httpsig
  • mtls
  • jwsd
  • jws

3.2 Grant response

Upon receiving a client instance request, the authorization server sends a grant response. In the grant response, 1 of the following token formats, defined in RFC 9767, should be used:

  • jwt-signed
  • jwt-encrypted

Bearer tokens should not be used as access tokens outside trusted internal systems. All access tokens should be bound to a key. ID tokens should use the "id_token" assertion format, which is defined in RFC 9635.

3.3 Interaction

The Cyber Centre recommends using the following:

  • the "redirect" interaction start mode
  • the "redirect" interaction finish method
  • 1 of the following hash methods for the interaction finish hash method:
    • sha-256
    • sha-384
    • sha-512
    • sha3-256
    • sha3-384
    • sha3-512
Top of page 

4 Fast Identity Online 2

Fast Identity Online 2 (FIDO2) is a framework consisting of 2 protocols: Web Authentication (WebAuthn) and the Client-to-Authenticator Protocol (CTAP). When used together, they allow a server, known as the relying party, to authenticate an end user using public key cryptography-based passkeys rather than traditional passwords.

The Cyber Centre recommends securing all communication between the relying party's server and application with TLS configured according to the guidance in Guidance on securely configuring network protocols (ITSP.40.062). Client-side applications should verify the authenticity of the server before performing any actions on behalf of the server.

Relying parties should use a WebAuthn application programming interface (API) provided by a web browser or operating system to perform FIDO2 operations.

4.1 Credential registration

In the "PublicKeyCredentialCreationOptions" object:

  • the "attestation" option should be set to "direct"
  • the "authenticatorSelection" option should have the following parameters:
    • "residentKey" set to "required"
    • "requireResidentKey" set to "true"
    • "userVerification" set to "required"
  • the "pubKeyCredParams" option should use 1 of the following for the "alg" parameter:
    • ES256 (ECDSA w/ SHA-256)
    • ES384 (ECDSA w/ SHA-384)
    • ES512 (ECDSA w/ SHA-512)
    • Ed25519 (EdDSA using Ed25519 curve)
    • Ed448 (EdDSA using Ed448 curve)
    • PS256 (RSASSA-PSS using SHA-256 and MGF1 with SHA-256)
    • PS384 (RSASSA-PSS using SHA-384 and MGF1 with SHA-384)
    • PS512 (RSASSA-PSS using SHA-512 and MGF1 with SHA-512
  • if none of the above "alg" parameter values are available, it is sufficient to use 1 of the following:
    • RS256 (RSASSA-PKCS1-v1_5 using SHA-256)
    • RS384 (RSASSA-PKCS1-v1_5 using SHA-384)
    • RS512 (RSASSA-PKCS1-v1_5 using SHA-512)

Relying parties should support the credential protection extension with the parameter "enforceCredentialProtectionPolicy" set to "true" and "credentialProtectionPolicy" set to "userVerificationRequired'.

Attestation should be required in the response to the credential creation request. In addition, the relying party should only accept an attestation that chains to a root certificate from a trusted source.

4.2 Authentication

The Cyber Centre recommends setting the "userVerification" option to "required" in the "PublicKeyCredentialRequestOptions" object.

The authentication should fail if the signature count received in an authentication response is less than or equal to the signature count that the relying party currently associates with the credential.

Top of page 
Date modified: