-
Notifications
You must be signed in to change notification settings - Fork 24
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
Re-design oxd Connect part to work inside user-agent instead of as backchannel app. #462
Comments
@nynymike I propose to make it in 4.3. Since it's not major release we can leave |
@yuriyz , what I understand from redirect to AS Authorization Endpoint --> user will enter username/password on login screen --> It will redirect back with code, id_token, access_token (depending on the flow) and validate --> call token endpoint (if required) and validate the token. I am confused if we need directly need to redirect to AS Authorization Endpoint and submit username/password from the screen or we need do it using below java code passing
|
When òxd |
Goal is to perform front channel calls, not backchannel as we do it now. |
Historically oxd was created to work as back-channel app via sockets. Later we introduced oxd-https-extension which later merged into oxd making http as main transport and removed sockets. oxd commands were designed as back-channel calls at that time. Now when oxd can work inside user-agent it should take advantage of it.
Remove current (in 5.x, in 4.3 mark as deprecated):
/get-authorization-url
/get-tokens-by-code
/get-logout-uri
Instead we should have
/authorize
which should redirect to AS Authorization Endpoint and on redirect back depending on type of the flow fetch token (or skip if it's Implicit Flow) and then validate it./end-session
In this way oxd will have full control of the process and we will not have questions like
how oxd should match UserInfo sub with id_token sub?
(see #441 (comment)).cc @nynymike
The text was updated successfully, but these errors were encountered: