OIDC login doesn't work when initiated with GET request
See original GitHub issueI’m testing against the IMS reference platform https://lti-ri.imsglobal.org/
OIDC login works if initiated with a POST
request, but not with a GET
request, which I believe tools should also support.
The code handling the login request looks for stuff into req.body
, but this will only work for POST
requests. For GET
requests, you will need to look into req.query
instead.
I’ve created a:
const params = { ...req.body, ...req.query }
to merge both, and that seems to work okay. Can’t believe Express doesn’t do that for us in 2020!
Anyway, looks like a simple fix.
Thanks for your awesome work on this library!
Issue Analytics
- State:
- Created 4 years ago
- Reactions:1
- Comments:7 (3 by maintainers)
Top Results From Across the Web
OpenID Connect (OIDC) authorization code flow mechanism
The Authorization Code Flow mechanism authenticates users of your web application by redirecting them to an OIDC provider, such as Keycloak, to log...
Read more >Spring Security OAuth2/OIDC RP-initiated logout does not work
This is why Spring Security allows it to be empty/null and doesn't complain. However, the oauth2Login() and logout() features, e.g. ...
Read more >Broken authentication (OIDC ): it was possible to re ... - GitHub
It means the logout doesn't work, it's a critical cyber security issue than a feature request. All reactions.
Read more >openid-client-initiated-backchannel-authentication-core
OpenID Connect allows Relying Parties (RP) to authenticate their users for clients of all types, including browser-based JavaScript and native mobile apps, to ......
Read more >OpenID Connect - Login.gov Developers
OpenID Connect is a simple identity layer built on top of the OAuth 2.0 protocol. Login.gov supports version 1.0 of the specification and...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Hello there Looks like it’s working great now, both with
GET
andPOST
. Thanks! I would like to see a little more debug output around the names of cookies it’s using, but other than that, it’s perfect, well done!Bad news I’m afraid, it’s not working properly, I’ve had to add some more debug to your code to work it out, I’ll try to explain 😃
If the platform sends a
GET
request to the/login
endpoint, it doesn’t have aOrigin
header (see https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Origin), so the code ends up using theHost
header, which will be my own tool’s URL, and that will be used to generate thestate
andiss
cookies.Later on, when the platform sends a
POST
request to the/
endpoint (it’s always aPOST
apparently), it does have aOrigin
header correctly set to the platform’s URLhttps://lti-ri.imsglobal.org
, so it will use that to search for cookies, and fail.The reason why I said it worked before (and probably why you also thought it worked!) is because I was testing against my tool running on my own computer, and this was over http rather than https, which means that the
POST
to/
had itsOrigin
set tonull
, so the code would use theHost
header again, and find the cookies this time.So… I don’t know enough about the LTI spec, and the use of the
Origin
vsHost
header, but it clearly doesn’t work in the current state.Hope my explanation is clear enough!