Push Protocol – Challenge/Response & Registration Redux
Author: |
David Luna |
Created at: |
Oct 2019 |
Updated at: |
Jul 2022 |
Overview
Push authentication depends on the secure verification of information
sent from the server to the client, and from the client to the server.
This lets the server verify that the notification was received by the
original device, and for the device to verify that only the server sent
the original request.
This approach is achieved by a combination of communication channels:
-
QR Code over HTTPS: Required for setup of the account on the user’s device. This allows an out-of-band setup of the device, and is of a sufficient security level for the goal of push authentication
-
Amazon Simple Notification Service: Used for delivering push messages to clients, which will trigger the authentication flow.
The high-level flow of operations is best summarized with the following diagram:
Registration
Registration is the process of registering the user’s phone with their account, so they can use it for push authentication-based login.
The flows described below assume an inline registration is being performed; that is, the user completes authentication using a conventional authentication chain, and within that, starts the registration process for the phone:
Authentication
The authentication flow assumes that both server and client have been preconfigured with the secret, and that the communication link between the server and the client has been established:
Data Contents
REG0 : Message sent from server to device via QR code
Format: URL-encoded within QR code
Scheme: pushauth://push.forgerock: _ _/? params
Where <username> is defined as:
The name of the account to display to the user on the phone’s app, usually the user-facing username of the account.
Where params are defined as:
Where loadbalancer is defined as:
Base64Url(loadbalancerName + “=” + loadbalancerValue)
The client should Base64Url-decode the string value as its cookie.
REG1 : Message sent from device to server in response to REG0
Format: JSON data payload , sent over HTTPS POST to the endpoint defined as the registration endpoint taken from REG0.
Where payload is defined as:
Where claims are defined as:
AUTH0 : Message sent from server to device via push
Format: Json data payload
Where payload is defined as below:
Signed JWT, with claims :
Where loadbalancer is defined as:
Base64(loadbalancerName + “=” + loadbalancerValue)
The client should first Base64-decode the string, and finally, use the value presented.
AUTH1 : Message sent from device to server in response to AUTH0
Format: JSON data payload , sent over HTTPS POST to the endpoint defined as the authentication endpoint taken from REG0.
Where payload is defined as:
Signed JWT, with claims :
Other Articles by This Author
Passkeys,
and other announcements from the FIDO Alliance, Apple,
Google, and Microsoft
[.badge-category__name#CTO
Lounge#]
Further steps towards passwordless adoption. The latest front in the war on passwords was opened recently via a multi-pronged attack by the FIDO Alliance, Apple, Google, and Microsoft. The announcement by the FIDO Alliance on the introduction of “passkeys” (or “multi-device credentials”) has been met with excitement by the Identity and Access Management community. At ForgeRock, we have been passionate about helping reduce the burden of passwords, and fully support these moves. The announcement …
Self-Sovereign Identity
Glossary
[.badge-category__name#CTO
Lounge#]
This glossary gives a (very) quick overview of the significant actors, roles, and components of a fully-realized Self-Sovereign Identity (SSI) solution. For more formal definitions, please see https://www.w3.org/TR/vc-data-model/#terminology Components Verifiable Credential (VC) A credential which has been generated about a given individual entity (Subject) by an Issuer. A credential is formed as a collection of attributes (or ‘claims’) that describe qualities of the subject. A Verifiable Cre…
Self-Sovereign Identity (SSI)—in the pure form that its most ardent supporters promote—envisions a situation where every user controls their own digital wallets containing verifiable credentials (VCs). The contents of these VCs are stored in immutable public blockchains and are shared to service providers through zero-knowledge proofs (ZKPs). Unfortunately, the real world is not ready for SSI. For a quick primer on the technologies, actors, and roles involved in SSI and how they interact, ref…
define web3
[.badge-category[.badge-category__name]CTO
Lounge#]
#define web3 The journey that we’re on… As we saw the emergence of Web2.0 (“web two point oh”) around 2003-2004 it changed the way users interacted with the world-wide web. No longer were static pages of information akin to an offline directory suitable for the modern web; it was time for dynamic content, and user participation. No longer were discussions between users hidden away in forums; it was time for comment sections and sites with built-in chat functionality. No longer was a user require…
How
To: Configure the SAML2 Authentication Module for Auto Federation in AM
[.badge-category__name#Setup#]
By David Luna A quick video tutorial on how to configure the SAML2 Authentication module for auto-federation in AM This demonstration walks through configuring the module from first principles, showing how to configure a service provider (SP), an identity provider (IdP), and then the Authentication module as part of a login chain. NOTE This video demonstration uses OpenAM 13.0; although the appearance has changed between AM and OpenAM 13.x, the same principles and processes still apply. In A…