Replies: 2 comments
-
|
ah, one missing understanding point, too:
|
Beta Was this translation helpful? Give feedback.
0 replies
-
|
Ok, found the solution myself, eg., the |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Hi,
I try to understand how to handle the OIDC workflow with fastapi-users.
I setup a OIDC provider, integrate into fastapi what ends up in two URLs:
/api/provider/authorize/api/provider/callbackAuthorize is clear: I call this returned URL, which points to the upstream provider (google/meta/...whatever). Now this provider calls the
/api/provider/callback- from it's point of view fine. But: of course there is just a json response with the accesstoken. From fastapi-users point of view right.What I try to understand is: How do I get my UI involved here again?
For now I would need to get the callback url after call to
/api/provider/authorize, strip out the/api/part, e.g, change it to/provider/callback, send this to the upstream provider (where this URL is of course allowed, too). Now it calls my UI with all information, I prepend again/apito it, send to the fastapi service and get now the bearer token into my app.Is this really this way or I'm totally lost? I saw that I could set my own routing path to
get_oauth_associate_routerbut this doesn't help, of course because than I have no API endpoint to call from UI perspective (nginx proxy redirects urls starting with/apito the backend, the rest goes into UI)so does anyone have an example for the OIDC login workflow where UI and backend is a bit separated as it often is? Or is it really just this way that I need to catch up the callback urls this way?
thanks for your help
Beta Was this translation helpful? Give feedback.
All reactions