Ki-Eun Shin <shin...@gmail.com>: Nov 18 11:30PM -0800
For the second use cases, you can get access token with the refresh token
without a user interaction like the conventional flow.
Do you want to authorize or authenticate again when the user visits again?
If you are a RP side, there are two ways to leverage this.
First approach is that register and use passkey credentials for your own
site and app regardless of OAuth2 provider.
1. Providing your own authentication mechanism (passkeys) with OAuth2. E.g,
after OAuth authorization (or onboarding process), you provide the way for
users to register passkeys on your site (your domain, RP id, and your app).
-> Meaning is that generated credential is only bound to your site and
app. (not to a OAuth2 provider)
2. Then, if the user visits your app or site again, if they need to
re-authenticate, then trigger passkey authentication in your site or app
(You don't need to redirect to the Idp.) This is not related to Oauth2
refersh or access token.
Just leverage authentication mechanisms provided by OAuth2 provider, if
they provide passkey authentication, then you can leverage as it was.
1. If OAuth2 provider offers passkeys somehow, user might register the
passkey in somewhere.
2. When, the explicit authorization or authentication is needed on OAuth2
provider, as you mentioned, perform PKCE flow. Then, the OAuth2 provider
triggers passkey authentication if they provide.
On Friday, November 18, 2022 at 11:32:07 PM UTC+9
Arshad Noor <arsha...@strongkey.com>: Nov 19 06:05AM -0800
Your question reminded me of a conundrum I have little understood. In
light of what FIDO brings to the authentication space, I am going to try
to challenge you (and others) to question your premise around "single
sign-on" (SSO) technology. The goal is not to put anyone on the
defensive about any specific SSO technology, but to debate whether SSO
is even necessary in light of what FIDO offers.
You have to step back into the late '80s and early '90s to understand
why SSO was really needed. Enterprises had a mish-mash of technology
solutions: mainframes running SNA LU6.2, mini-computers with DECNet and
other proprietary protocols, Netware LANs, a smattering of UNIX systems
running TCP/IP, and OS/2 with LAN Manager, etc. Everybody was using
usernames and passwords. And, everybody had different schemes,
algorithms, and protocols for dealing with them. The complexity of
managing this was daunting enough that companies were investing serious
money to solve this problem.
As networks were starting to coalesce around TCP/IP and public-key
cryptography made a splash, for a while in the late '90s, it seemed that
the password problem could be eclipsed by that original passwordless
authentication protocol - SSL ClientAuth - with X.509 v3 digital
certificates. But, that bubble broke with the dot-com crash; and
passwords that were restricted primarily to enterprise networks at the
dawn of the internet, exploded to affect every consumer that needed to
authenticate to a restricted website. Leading us to where we are today:
a mish-mash of SSO protocols and schemes.
FIDO is, essentially, a reboot. An advanced authentication technology that:
* Does NOT <https://dl.acm.org/doi/10.1145/1373290.1373293> depend on
"shared secret authentication";
* Is designed to protect the privacy of consumers;
* Can optionally leverage simple to sophisticated "user verification"
* Eliminates <https://fc16.ifca.ai/preproceedings/25_Lang.pdf>
password phishing attacks;
* Is supported on every modern client computing device (many with
* Is supported on every modern browser; and
* Most importantly, is simple enough that it can strongly authenticate
users with the touch of a button.
If a FIDO server can authoritatively return an authentication token in a
few seconds to any web/mobile application, why burden the application
with a legacy SSO protocol that adds yet another "band-aid" to what was
already a band-aid from the previous century? Why not cut the crap in
the middle and just get an authoritative answer from the source?
SSO tokens - whether they are SAML, JWT, etc. - must be verified
thoroughly because they represent a "man in the middle" of the
authentication flow; why introduce or maintain a man in the middle when
the protocol was designd for privacy. Why add the legal burden of
determining who is responsible for privacy violations when the MITM is
Ah! The answer is "legacy applications". SSO was written into
applications in an age when passwords ruled the world and companies
needed to alleviate the burden of users who were forced to authenticate
to dozens of systems within the enterprise. The cost of SSO was less
than the loss of productivity and consumer frustration with password
management that SSO is accepted as a defacto standard. But, when
passwords have been eliminated and strong authentication has been
simplified, does it make sense to continue carrying that cost of SSO?
The technical compexity? And, the legal burden in a world that is
increasingly regulating privacy? (Note that similar questions arise when
considering the issue
<https://github.com/fido-alliance/common-specs/issues/228> raised with
passkeys held by platform vendors).
It may be useful to step back and ponder whether it may actually benefit
the internet to eliminate the SSO burden - and its associated risks -
when an application can get an authoritative answer from a FIDO server
directly with the simple touch of a button, faster than we can verify
the authenticity and integrity of an SSO token.
On 11/18/22 6:32 AM, Lukas Westermann wrote: