If it were me, I would be looking at one of two options. If you have a number of resource servers, then I would have one AS that would manage authentication and authorization of the client. This enables separation of concerns of client authn and authz from the RS, and puts client blacklisting in one place. The client sends its request to the AS signed by its key, and the AS returns an access token to be used against the RS. You could layer on DPoP if needed.
If there is really only one service, then there is little value in an AS. I would have the client post a JWT that has the request payload in it, or a detached signature if it is a large payload. Personally, I like sending the request as a JWT as it allows services further down the processing pipeline to independently verify the request from the client. This assumes sufficient computing power on the IoT device, and reasonably low call volume. ᐧ On Thu, Sep 30, 2021 at 9:45 PM <[email protected]> wrote: > Thanks Dick, > > > > Our use case is to connect IoT devices to a cloud service. The cloud > service has > > to authenticate those devices. The devices are not operated by humans. > They run > > on its own. > > > > We want public key-based authentication for those devices. In that case, > mutual > > TLS is a popular option (e.g. AWS IoT Core). However, we don't want to use > > mutual TLS for several reasons (e.g. it's too coupled with the transport > layer). > > So, we are seeking a solution that is more in application layer. > > > > > > Toshio Ito > > > > *From:* Dick Hardt <[email protected]> > *Sent:* Friday, October 1, 2021 12:53 PM > *To:* ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [OAUTH-WG] self-issued access tokens > > > > Would be useful to understand your use case and what you the goals and > constraints are > > > > On Thu, Sep 30, 2021 at 5:58 PM <[email protected]> wrote: > > Thanks Dick, > > > > I agree. The scenario of self-issued access tokens doesn't really follow > the > > model of OAuth. > > > > So, if we do standardize self-issued access tokens, maybe OAUTH WG is not > the > > right venue. Maybe HTTPBIS or HTTPAPI WGs? > > > > > > Toshio Ito > > > > *From:* Dick Hardt <[email protected]> > *Sent:* Wednesday, September 29, 2021 3:06 PM > *To:* ito toshio(伊藤 俊夫 ○ＲＤＣ□ＩＴ研○ＣＮＬ) <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [OAUTH-WG] self-issued access tokens > > > > 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. > > > > > > > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
