🚀 Feature: store auth method (passkey, e-mail, code) in claim #78

New Issue

OVERLORD · 2025-10-09T16:25:14+03:00

OVERLORD commented

2025-10-09 16:25:14 +03:00

Originally created by @peterforeman on GitHub.

Feature description

Optionally add the method of authentication (software passkey, hardware token, by e-mail or code) to the access token claims. This way the app can check for how (securely) the user logged in and optionally prevent access to most secured areas.

An easier, but less flexible way would be to add a Boolean to the oidc client "Require passkey login" or something, denying access to the app when the user does not login with a passkey.

Pitch

Passkeys are great. But not all my users are comfortable with them yet. So many use e-mail auth as method. For most apps this is fine for us, but for some apps (or areas of apps) I would like to require the user to use a passkey. Even nicer would be to be able to check if a physical key has been used.

Originally created by @peterforeman on GitHub. ### Feature description Optionally add the method of authentication (software passkey, hardware token, by e-mail or code) to the access token claims. This way the app can check for how (securely) the user logged in and optionally prevent access to most secured areas. An easier, but less flexible way would be to add a Boolean to the oidc client "Require passkey login" or something, denying access to the app when the user does not login with a passkey. ### Pitch Passkeys are great. But not all my users are comfortable with them yet. So many use e-mail auth as method. For most apps this is fine for us, but for some apps (or areas of apps) I would like to require the user to use a passkey. Even nicer would be to be able to check if a physical key has been used.

OVERLORD added the needs more upvotes label 2025-10-09 16:25:14 +03:00

OVERLORD commented

2025-10-09 16:25:16 +03:00

@peterforeman commented on GitHub:

Great find! The amr would be a good one, also because it's an array format so you can really get into what methods (or levels) are used.

I guess that if we implement the 'amr' claim with values phr, pop, swk, hwk and otp we would at least have a basic but very useful form which seems to be adopted more widely than the acr claim?

You then could also implement:

OIDC client configuration where you can select which 'amr' values should be present to be allowed, effectively blocking all access to an app
A route (with callback/returnTo) to redirect the client to to force passkey login (e.g.: request/force a higher level of security), to be used from the client itself if you don't want to block all access but perhaps only parts of the app

I'm not really into the webauthn spec, but since the values are in the IANA spec I would assume we can distinguish between the type of key (hardware/software) in the code?

@peterforeman commented on GitHub: Great find! The amr would be a good one, also because it's an array format so you can really get into what methods (or levels) are used. I guess that if we implement the 'amr' claim with values phr, pop, swk, hwk and otp we would at least have a basic but very useful form which seems to be adopted more widely than the acr claim? You then could also implement: - OIDC client configuration where you can select which 'amr' values should be present to be allowed, effectively blocking all access to an app - A route (with callback/returnTo) to redirect the client to to force passkey login (e.g.: request/force a higher level of security), to be used from the client itself if you don't want to block all access but perhaps only parts of the app I'm not really into the webauthn spec, but since the values are in the IANA spec I would assume we can distinguish between the type of key (hardware/software) in the code?

OVERLORD commented

2025-10-09 16:25:17 +03:00

@ItalyPaleAle commented on GitHub:

I've been doing some research on this. It seems that the standard claim to include would be amr (RFC).

This is an array that can include multiple values. Most of the values are documented in the IANA spec. Some relevant to Pocket ID:

phr ("phishing resistant") seems to be the de-facto standard for passkeys, even if that's not part of the IANA list. Auth0 uses it too: https://auth0.com/blog/all-you-need-to-know-about-passkeys-at-auth0/
pop ("proof of possession of a key") -> I guess we could use this for all passkeys too?
- swk ("Proof-of-possession of a software-secured key") -> We could use it for software-based passkeys (like 1Password or iCloud)
- hwk ("Proof-of-possession of a hardware-secured key") -> We could use it for hardware-based passkeys (like YubiKeys)
otp ("One-time password") -> Seems to be the one to use for both login codes and email-based logins

There's an additional, claim acr which can be used to indicate the "security level". This can be an "absolute URI" or a "registered value" with RFC6711. The only ones that seem generic defined in the IANA database are phr (Software passkey) and phrh (Hardware passkey). Or we could define our own such as pocketid:acr:phr (software passkey), pocketid:acr:phrh (hardware passkey) , pocketid:acr:email, pocketid:acr:lc (login code). We could alternatively go a different route and define them as "levels", such as pocketid:acr:high for passkeys, and pocketid:acr:low for login codes.

@ItalyPaleAle commented on GitHub: I've been doing some research on this. It seems that the standard claim to include would be `amr` ([RFC](https://openid.net/specs/openid-connect-core-1_0.html#IDToken)). This is an array that can include multiple values. Most of the values are documented in the [IANA spec](https://www.iana.org/assignments/authentication-method-reference-values/authentication-method-reference-values.xhtml). Some relevant to Pocket ID: - `phr` ("phishing resistant") seems to be the de-facto standard for passkeys, even if that's not part of the IANA list. Auth0 uses it too: https://auth0.com/blog/all-you-need-to-know-about-passkeys-at-auth0/ - `pop` ("proof of possession of a key") -> I guess we could use this for all passkeys too? - `swk` ("Proof-of-possession of a software-secured key") -> We could use it for software-based passkeys (like 1Password or iCloud) - `hwk` ("Proof-of-possession of a hardware-secured key") -> We could use it for hardware-based passkeys (like YubiKeys) - `otp` ("One-time password") -> Seems to be the one to use for both login codes and email-based logins There's an additional, claim `acr` which can be used to indicate the "security level". This can be an "absolute URI" or a "registered value" with RFC6711. The only ones that seem generic [defined](https://openid.net/specs/openid-connect-eap-acr-values-1_0.html#acrValues) in the IANA database are `phr` (Software passkey) and `phrh` (Hardware passkey). Or we could define our own such as `pocketid:acr:phr` (software passkey), `pocketid:acr:phrh` (hardware passkey) , `pocketid:acr:email`, `pocketid:acr:lc` (login code). We could alternatively go a different route and define them as "levels", such as `pocketid:acr:high` for passkeys, and `pocketid:acr:low` for login codes.

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/pocket-id-pocket-id-2#78