Singpass Developer Docs
Legacy Myinfo v3/v4
Legacy Myinfo v3/v4
  • Legacy Myinfo v3/v4
  • Data Catalog
  • Key Principles
  • Technical Specifications
    • Myinfo v4
      • Difference between v3 and v4
      • Technical Guidelines
      • Technical Concepts
        • OAuth 2.1 Concepts
        • Proof of Key Code Exchange (PKCE)
        • JSON Web Token (JWT)
        • Client Assertions
        • JSON Web Key Store (JWKS)
        • Demonstration of Proof-of-Possession (DPoP)
      • API Specifications
      • Tutorials
        • Tutorial 1: Myinfo Person sample Data
        • Tutorial 2: End-to-end Integration with Myinfo v4 APIs
      • Resources
        • Myinfo Connectors
        • Error Codes
      • FAQ
    • Myinfo v3
      • Technical Guidelines
      • API Specifications
      • Latest X.509 Public Key Certificate
      • Tutorials
        • Tutorial 1: Basic Person API
        • Tutorial 2: Using OAuth2
        • Tutorial 3: Implementing PKI Digital Signature
      • Resources
        • Myinfo Connectors
        • Error Codes
      • FAQ
Powered by GitBook
On this page

Was this helpful?

  1. Technical Specifications
  2. Myinfo v4
  3. Technical Concepts

Proof of Key Code Exchange (PKCE)

PreviousOAuth 2.1 ConceptsNextJSON Web Token (JWT)

Last updated 1 month ago

Was this helpful?

Proof Key for Code Exchange(PKCE) is an extension to the Authorization Code flow to prevent Cross Site Request Forgery(CSRF) and Authorization code injection attacks. (Refer to )

  1. User access to the client application.

  2. Client application creates a cryptographically random string as a secret key (code_verifier) that only it knows and creates a base64url encoded hash of the secret key(code_challenge).

  3. Client application returns the code_challenge and creates a frontend session to the user's browser.

  4. Browser calls /authorize API with the code_challenge.

  5. The AuthZ server returns the authcode.

  6. Client application calls /token API with the code_verifier and authcode.

  7. The AuthZ server will ensure that the code_verifier has the same hash as the code_challenge before issuing the access_token.

i) Create code_verifier


Create a code_verifier, which is the cryptographically random string that will eventually be sent to Token API to request for access_token.Copy to clipboard

// Dependency: Node.js crypto module (https://nodejs.org/api/crypto.html#crypto_crypto)
 
function base64URLEncode(str) {
    return str.toString('base64')
        .replace(/\+/g, '-')
        .replace(/\//g, '_')
        .replace(/=/g, '');
}
 
// The client generates a random string of bytes and saved into a persistent session store
let codeVerifier = base64URLEncode(crypto.randomBytes(32));

i) Create code_challenge


Using the code_verifier, generate a code_challenge that will be sent in the /authorize API. Copy to clipboard

// Dependency: Node.js crypto module (https://nodejs.org/api/crypto.html#crypto_crypto)
 
function base64URLEncode(str) {
    return str.toString('base64')
        .replace(/\+/g, '-')
        .replace(/\//g, '_')
        .replace(/=/g, '');
}
 
// The client hashes these bytes and encodes them for use in a url
let codeChallenge = base64URLEncode(crypto.createHash('sha256').update(codeVerifier).digest());

code_challenge should be generated from the raw bytes of the code_verifier and not the hex encoded string. Example: 'helloworld' code_verifier should produce 'k2oYXKqiZrucvpgengXLeM1zKwsygOuURBK7b4-PB68' as code_challenge

https://datatracker.ietf.org/doc/html/rfc7636