Re: IPP OAuth 2.0 question / potential gap: How should the Client manage multiple access tokens or realm identities?
Michael Sweet via ipp <[email protected]>
| Newsgroups | gmane.ietf.ipp |
|---|---|
| Message-ID | <[email protected]> |
Smith, If I am reading this right it looks like they are saying we should treat different hostnames as different OAuth "realms", which seems to be an obvious answer. I would go slightly farther and say the combination of "oauth-authorization-server-uri" and "oauth-scope" should be used when caching authorization tokens for a given realm, and "oauth-authorization-server-uri", "oauth-scope", and "printer-uri" (or "server-uri") for access tokens (since token exchange yields device/service-specific tokens). > On Oct 13, 2022, at 4:37 PM, Kennedy, Smith (Wireless & IPP Standards) <[email protected]> wrote: > > > >> On Oct 13, 2022, at 2:25 PM, Kennedy, Smith (Wireless & IPP Standards) via ipp <[email protected]> wrote: >> >> Signed PGP part >> CAUTION: External Email >> >> Hi there, >> >> I was having another discussion with HP's OAuth 2.0 folks over the last few days, and one of the things they are working on is guidance for the client on how it should or could manage the circumstance where the client device holds access tokens for multiple "realms" (i.e., work printing, home printing). If it was all just local information similar to Wi-Fi "profile" information maintained on the client, that would just be left up to the client's implementation. >> >> I found this page that seems to talk through some of these concepts. > > > Here's the link I meant to provide, which discussed it from an OIDC perspective: https://developer.okta.com/docs/guides/oin-oidc-multi-tenancy/main/#tenants-in-okta > >> I will continue to read, but wanted to share in case others have already developed plans or thoughts in this area, that we could leverage. >> >> Cheers, >> >> Smith >> >> /** >> Smith Kennedy >> HP Inc. >> */ >> >> > ________________________ Michael Sweet