Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User Story: As a developer, I don't want to leave my app during federated authentication #10

Open
hpsin opened this issue Oct 27, 2021 · 3 comments

Comments

@hpsin
Copy link

hpsin commented Oct 27, 2021

User story

When users visit my app and I ask them to sign in, I don't want to navigate away from my app. Instead, I want to embed the login experience in an iframe inside my app.

Context of the story

Some IdPs support embedding of their UX in an iframe, allowing "inline" authentication experiences that still benefit from SSO,

Should this be considered sanctioned or unsanctioned tracking?

Sanctioned

Explicit list of parties involved

IDP
User
Application

Complicating characteristics

This is a zero-navigation, iframe-based authentication that is nevertheless interactive. It does not have a full-page redirect that can be intercepted. When the iframe is loaded, the IdP will have no access to existing sessions, potentially causing the user to need to authenticate multiple times across apps that use this pattern.

Additional information

This is a prime candidate for the initial implementation of the Storage Access API, wherein an IdP would trigger the prompt and regain access to its 1st party cookies.

@brdaugherty
Copy link

Use case to consider: RPs hosting multiple TLDs and trying to sign users in once with persistent a user session as a user-agent visits multiple TLDs in the managed group.

@hlflanagan
Copy link
Contributor

Discussed during the 12 November 2021 fedidcg call

@NekR
Copy link

NekR commented Feb 13, 2022

I personally feel like it isn't safe to include credentials authentication inline with <iframe>, because user doesn't see the URL and cannot really trust the page. All users see is "it's okay and popular pattern to have inline authentication on Google" so when it pops-up on a scammers website, it doesn't raise any questions and bad things happen.

But with in new system and User Agent's UI it could be "verifiable" somehow, e.g. when use clicks "Auth with Google" and it shows inline authentication with some verification from User Agent that yes, it's from Google.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants