If the client is sending a self-signed JWT to the RS, you essentially are just authenticating directly to the RS. Not really OAuth as the RS has not delegated authorization authority to the AS.
If the client sends a self-signed JWT (a PAR) to the AS, and gets back an access token to present to the RS, you get centralized authorization decisions, a key feature of OAuth. ᐧ On Tue, Sep 28, 2021 at 6:55 PM <[email protected]> wrote: > Hi OAuth folks, > > I have a question. Is there (or was there) any standardizing effort for > "self-issued access tokens"? > > Self-issued access tokens are mentioned in a blog post by P. Siriwardena > in 2014 > [*1]. It's an Access Token issued by the Client and sent to the Resource > Server. > The token is basically a signed document (e.g. JWT) by the private key of > the > Client. The Resource Server verifies the token with the public key, which > is > provisioned in the RS in advance. > > I think self-issued access tokens are handy replacement for Client > Credentials > Grant flow in simple deployments, where it's not so necessary to separate > AS and > RS. In fact, Google supports this type of authentication for some services > [*2][*3]. I'm wondering if there are any other services supporting > self-signed > access tokens. > > Any comments are welcome. > > [*1]: > https://wso2.com/library/blog-post/2014/10/blog-post-self-issued-access-tokens/ > [*2]: > https://developers.google.com/identity/protocols/oauth2/service-account#jwt-auth > [*3]: https://google.aip.dev/auth/4111 > > ------------- > Toshio Ito > Research and Development Center > Toshiba Corporation > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
