goauthentik / goauthentik/authentik
Persisting context after SSO/Social/Source flow
- Dominant language
- Python
- Stars
- 25.6k
- Forks
- 2k
- Avg merge
- 1d 2h
- Merged PRs (30d)
- 651
Description
**Describe your question/**
I've been playing around a bit with flows involving SSO logins, and from what I've gathered any context that is set/created before the SSO login isn't retained through redirect/return to an external IDP. I'm barely remembering something I did a while back to get this to work, but I can't for the life of me find it or remember it now.
The two specific use cases I'm currently trying out are:
### "Source flow" for social/external providers
Setting up a single social application, and then combining it with different authentication flows. Currently, there are two options for this:
1. Setting up an authentication flow and an associated social login (1:1)
2. Setting up an authentication flow and a separate flow for social/source auth, and then redirect the user to the "regular" authentication flow
What I've been trying to accomplish is setting a policy on the "regular" authentication flow ("original_flow") setting something like ``` context["flow_plan"].context["source_flow"] = 'original_flow' ```, so that we can use that to redirect the user back from the social/source auth flow (sso_flow) to the original flow, but it seems that the previous context from before the OIDC login is called is lost/discarded
### Social Invitations
The same goes for invitations paired with social logins. I did find a blog post/github repo that has one way to do it, which depending on the strategy requires a separate set of social login providers for each login flow or even a separate set of social login providers for each login flow and registration/authentication pair.
Am I missing something, or is this how it currently works/is supposed to work?
**Relevant info**
n/a
**Screenshots**
n/a
**Logs**
n/a
**Version and Deployment (please complete the following information):**
- authentik version: 2024.12.1
- Deployment: Tried with both helm & docker-compose
Contributor guide
Research direction
No files, tests, or entry points are named. Start by tracing the SSO, social/source, and external IDP redirect and return flows, then determine where pre-login context is discarded; done should establish and verify the intended handling of context for source flows and social invitations.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- docker-compose, helm, python
- Domain
- authentication, authorization
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100