Thanks Neil & Hans,
Our AS doesn't do jwt quite yet. It's in-house, but open source. We
don't have rfc7523 yet, but this does sounds like a pretty great
longer-term solution.
We're a bit time constrained, so perhaps this feature just needs to be
done as a one-off before we can do RFC7523 for real, later.
Thank you!
On 2021-03-02 3:05 p.m., Neil Madden wrote:
One option is JWT Bearer grant with “jti” and replay prevention
(https://tools.ietf.org/html/rfc7523#page-7
<https://tools.ietf.org/html/rfc7523#page-7>) if your AS supports it.
This is nice if some other component is generating the emails as it
needs no coordination with the AS.
— Neil
On 2 Mar 2021, at 19:04, Evert Pot <[email protected]> wrote:
Dear list,
We have a requirement to let users log in to an application via a
code sent by email.
This code needs to be exchanged for an access/refresh token pair, and
should only work once.
The access/refresh token scope would give limited access to the
application. Since we already use the authorization_code flow for
other (more sensitive) parts of the application, I would like to
re-use the OAuth2 framework for parts of this.
It doesn't sit right with me to overload the 'code' in
authorization_code, so I was considering introducing a new custom
grant_type for our application, specific for this purpose.
It seems that grant_type in the 'token' endpoint would support
extension in this manner, by using a uri such as
https://vendor.example/email-token
I'm comfortable implementing this, but curious:
1. Is there already some prior art that I'm not aware of? I'd rather
not do a custom grant_type if there's something standard I could do.
2. Are there any major pitfalls associated with this?
Evert
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
ForgeRock values your Privacy <https://www.forgerock.com/your-privacy>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
