JanssenProject / JanssenProject/jans
Implement "Initiating Login from a Third Party" section of OIDC core spec
@yuriyz is already working on this.
Since Mar 10, 2023.
- Dominant language
- Java
- Stars
- 648
- Forks
- 174
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 110
Description
_aliaksander-samuseu commented on Nov 4, 2019_
[This section of the spec](https://openid.net/specs/openid-connect-core-1_0.html#ThirdPartyInitiatedLogin) allows for OP (or actually any 3rd party service) to initiate OIDC flow (in contrary to the usual sequence when it's started by RP). As of now, if oxAuth's login page is accessed by direct link, its behaviour isn't very useful. If no session context exist at all, an error page is usually displayed. If a valid authenticated session exists at oxAuth already, its login page is displayed, and if credentials are submitted, existing session context is used to redirect user to some RP's `redirect_uri` (what isn't always useful).
It would be perhaps more reasonable to redirect users to a new oxAuth selector page where they can choose RP (or SAML SP) they want to be logged in to. For OIDC RPs, the mentioned core spec section could be implemented, so users could start OIDC flow to RPs supporting it from oxAuth. For SAML SPs (and OIDC RPs that don't explicitly support this part of spec), a simple redirect to SP's sign-in url could be done instead.
A few notes:
The new selector page should be accessible directly as well (so users could bookmark it, for example). In such case, upon going there, users will be sent to oxAuth for authentication, if needed, then back at selector page where they will choose which service to log in to; so the selector page could be represented by OIDC client itself, functioning as mini-RP, a separate module (service running in its own JVM, similar to `oxauth-rp` used for QA)
We already have a similar feature as part of our IDP-initiated Inbound SAML (with Passport) flow, so it could be reasonable to use it as a foundation, or substitute it with the new feature (to prevent having 2 different modules implementing very similar features)
_nynymike commented on Jan 17, 2020_
If we did implement this, it would need to be configurable via a property.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.