ORCID
PKCE support and CORS on OAuth token endpoint
At least by available documentation PKCE does not seem to be supported on OAuth endpoints. Moreover, I tested and CORS requests are not supported on OAuth token endpoint. Allowing those two things allow one to use explicit flow on the frontend/client as well instead of the implicit flow. Implicit flow is deprecated because modern browsers support CORS requests. So one can obtain authorization code and then issue the request against the token endpoint to obtain an access token.
More information:
- https://tools.ietf.org/html/rfc7636
- https://www.oauth.com/oauth2-servers/pkce/
- https://auth0.com/docs/flows/concepts/auth-code-pkce
- https://developer.okta.com/blog/2019/08/22/okta-authjs-pkce
Hi Mitar,
Thanks for your well researched issue.
It was a deliberate decision to not allow token requests over CORS for security reasons, and at the time PKCE was not considered, probably because our servers were created before https://tools.ietf.org/html/rfc7636 was released. Instead we support implicit OAuth but limit the permissions that can be granted through this process to reading public information only.
From what I'm reading, this looks like it may a mechanism for purely client side integrations to perform secure updates to ORCID records, but I will need to read closer to understand properly.
I have created a card on our feedback board. https://trello.com/c/3A5mdVZ1/58-oauth-pkce-cors-support and we will analyse the feasibility of this concept. I suspect this would be a significant amount of work to implement, and I do not yet have an idea of how or how much it would be used. For that reason, it's not something we will be able to prfioritize at the moment. However, we do move with the times, and if our members are asking us for it, it may happen at some point in the future.
Instead we support implicit OAuth but limit the permissions that can be granted through this process to reading public information only.
So I think it is a separate question what scopes you allow to obtain for public (those which cannot hold secrets) clients. I am fine with just public scopes. (Public clients are formally defined in the OpenID/OAuth specs.)
But the methods how to obtain those tokens (implicit flow vs. token + PKCE) I think should not matter. Moreover, token + PKCE is newer and more secure than implicit flow.
From what I'm reading, this looks like it may a mechanism for purely client side integrations to perform secure updates to ORCID records, but I will need to read closer to understand properly.
Yes, you could expand which scopes you allow for public clients I would say, no matter the mechanism how they authenticate. But I am not advocating for that here, BTW.
However, we do move with the times, and if our members are asking us for it, it may happen at some point in the future.
I do understand that you have limited resources and you have to manage them well, but to me this question is less about user demand and more about offering improved security. See this draft spec for more information: https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15, more specifically https://tools.ietf.org/html/draft-ietf-oauth-security-topics-15#section-2.1.2
https://www.oauth.com/oauth2-servers/pkce/
In later years, it was recognized that its ability to prevent authorization code injection makes it useful for every type of OAuth client, even apps running on a web server that use a client secret. Because of its history in the use of mobile apps and single-page apps, it is sometimes incorrectly thought that PKCE is an alternative to a client secret. However PKCE is not a replacement for a client secret, and PKCE is recommended even if a client is using a client secret, since apps with a client secret are still susceptible to authorization code injection attacks.
I am closing this as the feedback has been captured on our community board and we're in the process of prioritising this. I hope to get to it in 2023.