--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CANpA1Z3sg22Q%3DjfDZ7AeD__G4QLPNnJu7zoQ2tCgkgzYQGEH_g%40mail.gmail.com.
Damn this video cleared up a lot of confusion for me
regarding OAuth 2.0 (authorization) and reminded me on OpenID Connect.
Now, I am trying to recall if there was something
like OpenID message/post/comment signing.
Regarding „OAuth scopes“: There seems to be the
assumption in the "allow" screen that granting of
access is all or nothing of the requested scopes.
Nor seems there be any obvious way for the authorization service to tell the „client“ in the
callback "here is the url endpoint of the contact list the user wants you to access" in the yelp example used in the video.
The user could have been
asked at the "allow" screen which of her contact lists she wants that app access to. Could probably
specified in the access token returned though with
the „client“ none the wiser.
Basically I am saying there is lack of designation in
the authorization.
Then there is the lack of further delegation and
authority attenuation.
But I hold forth that functionality could be built on top. At least the attenuation part.
Possibly by an "unholy" combo of jwt and macaroons.
(a jwt caveat inside the macaroon)
Wash your hands thoroughly!
-Baldur
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/4888829f-dda0-4acd-83d5-b964c785391f%40googlegroups.com.
Comments inline.
--------------
Alan KarpOn Fri, Mar 27, 2020 at 8:33 PM Baldur Jóhannsson <zaru...@gmail.com> wrote:Damn this video cleared up a lot of confusion for me
regarding OAuth 2.0 (authorization) and reminded me on OpenID Connect.
Now, I am trying to recall if there was something
like OpenID message/post/comment signing.I haven't heard of anything.
Regarding „OAuth scopes“: There seems to be the
assumption in the "allow" screen that granting of
access is all or nothing of the requested scopes.That's because clients are only supposed to ask for the scopes they actually need, and supposedly more people will say no if they ask for a lot. Ha, Ha. There was also a discussion of a "step-up" flow where you could ask for more permissions later, but I don't think anything came of it
Nor seems there be any obvious way for the authorization service to tell the „client“ in the
callback "here is the url endpoint of the contact list the user wants you to access" in the yelp example used in the video.The client hits the resource URL, gets redirected to the authorization server, gets the grant followed by the token. It then goes back to the original URL. The client has to remember that URL. The token would have been an ocap if they had put the URL in the token.
The user could have been
asked at the "allow" screen which of her contact lists she wants that app access to. Could probably
specified in the access token returned though with
the „client“ none the wiser.
Basically I am saying there is lack of designation in
the authorization.Lots of features were discussed, but it was decided to keep things really simple for the user.
Then there is the lack of further delegation and
authority attenuation.
But I hold forth that functionality could be built on top. At least the attenuation part.
Possibly by an "unholy" combo of jwt and macaroons.
(a jwt caveat inside the macaroon)That's the token exchange in RFC 8693. It didn't exist when the video was made.
The next version of my employer’s (ForgeRock) OAuth2 authorization server software
When you inspect the access token using the authorization server’s introspection endpoint it returns the most restrictive combination of the original token and any caveats attached to it:- the scope is the intersection of the original token scope and any scope caveats- the audience is the intersection too
- the expiry time in the minimum of the original expiry time and any caveatsEtc
Neil Madden <neil....@forgerock.com> wrote:The next version of my employer’s (ForgeRock) OAuth2 authorization server softwareIt's good to have someone who really knows this stuff on cap-talk, rather than just a dilettante like me.I think having multi-audience tokens is a mistake unless audience members are listed in the token. Without that, you don't know who to tell that the token has been revoked. Also, you don't know if you're sending the token to a valid end point, so you need further complications, such as client secret. Is there a good reason to do multi-audience the way OAuth does it?When you inspect the access token using the authorization server’s introspection endpoint it returns the most restrictive combination of the original token and any caveats attached to it:- the scope is the intersection of the original token scope and any scope caveats- the audience is the intersection too
- the expiry time in the minimum of the original expiry time and any caveatsEtcA question we wrestled with when doing the Zebra Copy work was whether or not to reject if any of the delegations was invalid even if the aggregate was OK. We opted for the former. It sounds like you decided on the latter.
Do you support revocation, or do you rely on expiration time only? If you support revocation, who can revoke? Zebra Copy allowed anyone on the delegation chain to revoke any subsequent delegation, but it might be better had we allowed revoking only the direct delegation.
I don’t think so, but people do it anyway. I think there is a strong preference to avoid prompting users for consent multiple times (leading to “consent fatigue”), so developers try to get do-everything access tokens in one go that can be used for multiple APIs.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/2C820511-ECDD-425C-82E4-B2D97310E85C%40forgerock.com.
Is there a good reason to do multi-audience the way OAuth does it?
I don’t think so, but people do it anyway. I think there is a strong preference to avoid prompting users for consent multiple times (leading to “consent fatigue”), so developers try to get do-everything access tokens in one go that can be used for multiple APIs.
Macaroons let you get one uber-token and then derive more specific tokens from it on-demand, which hopefully will guide developers back to a least-authority approach.
We support revocation in a few ways:Firstly, users can go into their profile and revoke all access to a particular client (app/developer). This revokes all existing tokens issued to that client by that user.
We also support RFC 7009 token revocation, which allows the client to revoke their own tokens. (They limited it to just the client apparently to rule out malicious revocation, but to my mind revoking a token you have somehow got hold off is the most responsible thing you could do with it).
Or the token can be a self-contained token like a JWT. In this case the RS typically has no way to know when it is revoked. We would recommend people use short-lived access tokens in this case and issue the client with a longer-lived refresh token to get a new access token: refresh stops working when the token is revoked.
Neil Madden <neil....@forgerock.com> wrote:Is there a good reason to do multi-audience the way OAuth does it?I don’t think so, but people do it anyway. I think there is a strong preference to avoid prompting users for consent multiple times (leading to “consent fatigue”), so developers try to get do-everything access tokens in one go that can be used for multiple APIs.Which is, of course, a POLA violation. I would rather see a do-everything grant that can be turned into finer grained tokens. I guess the token exchange RFC can serve the same purpose, but people might not use it.
Macaroons let you get one uber-token and then derive more specific tokens from it on-demand, which hopefully will guide developers back to a least-authority approach.If you can get developers to do that. Since it's extra work on their part, I wonder if it will be as widely applied as it should be.
Why did you decide to accept even if an individual delegation in the chain was invalid? We considered an invalid delegation to be a bug, which meant we couldn't know the delegator's intent.
Does that assume a client ID, or do you just tie it to the redirect URI? I'm not a fan of the client ID/secret approach, because it requires a prior relationship between the client and RS. Also, before token exchange, there was no way to re-delegate without sharing your client secret.We support revocation in a few ways:Firstly, users can go into their profile and revoke all access to a particular client (app/developer). This revokes all existing tokens issued to that client by that user.
Stiegler and I went back and forth on this one for SCoopFS. We ended up allowing anyone holding a capability to revoke it, because it was almost always what users wanted. There was a potential denial of service, since anyone could revoke the whole delegation chain. I think the right answer is to make the ability to revoke one of the scopes.We also support RFC 7009 token revocation, which allows the client to revoke their own tokens. (They limited it to just the client apparently to rule out malicious revocation, but to my mind revoking a token you have somehow got hold off is the most responsible thing you could do with it).
Or the token can be a self-contained token like a JWT. In this case the RS typically has no way to know when it is revoked. We would recommend people use short-lived access tokens in this case and issue the client with a longer-lived refresh token to get a new access token: refresh stops working when the token is revoked.Since Zebra Copy did not have multi-audience tokens, we could just send the revocation request directly to the RS, which only needed to remember the GUID for each revoked certificate until it expired.
That's because clients are only supposed to ask for the scopes they actually need, and supposedly more people will say no if they ask for a lot. Ha, Ha.
The bigger problem, from a practical standpoint, is that OIDC utterly relies on the browser redirect method, and is consequently a real PITA for desktop applications to use.
--
You received this message because you are subscribed to the Google Groups "cap-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cap-talk+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/cap-talk/CAAP%3D3QNG%3DARbn3xz35XK5UtWZkDZqegctMU7cbSmeKzaD0zdNg%40mail.gmail.com.
This thread has sort of died down, but I've run across an issue with OIDC that I wanted to share.Context: we're building a service where most customers are business entities. We'd like to support SSO for these clients, and it turns out that many already have an OIDC or SAML authentication service of some sort even if they don't realize it. If you are using Google Workspace (formerly GSuite) or you are signed up on Azure AD (including any of the onmicrosott.com domains), you already have an IdP/OP. And it would be really nice to be able to facilitate onboarding by having a way to automatically locate your provider. User sh...@buttonsmith.com shows up, and we'd like to know where to authenticate buttonsmith.com identities. For OIDC, there isn't a practical way, which is surprising in a system where SSO is touted as a feature.The OpenID foundation currently recommends that "consuming" companies implement a protocol called WebFinger (RFC7033). The overwhelming majority of entities who use OpenID in a corporate context are tiny businesses who haven't the ability to stand that up. An awesome number of them run their primary domain off of Shopify or BigCommerce or some such hosted service, which means they really don't have the option to stand up a WebFinger server.
But...There is something called OpenID Connect Discovery. Under OIDC Discovery, an OP/IdP publishes everything one needs to access the IdP/OP is published as a JSON document at http://host/.well-known/openid-configuration. Or rather, any path ending in that, though in practice everybody uses /.well-known on their sites. Since the endpoint resource names can be anything, this lets you find them with minimal hassle.
The small change here would be to let the web server for any domain publish this document, with the intended meaning that "if you are trying to authenticate a user in our domain, here's the information on the IdP/OP to use." The replying party works its way up the domain tree looking for the endpoint config. If I give my email as sh...@mumlble.buttonsmith.com, then mumble.buttonsmith.com is tried first and then buttonsmith.com is tried. To avoid update problems when the IdP/OP changes its endpoints, the version published at buttonsmith.com could simply be a redirect.
All of the major commerce sites can support this. Knowing who the IdP/OP is doesn't absolve the resource provider of needing to decide if they will trust it, but that's a much easier problem.I find myself wondering how something so obvious and simple was neglected in favor of something so impractical (WebFinger).Hardly the end of the world, but frustrating.
WebFinger is also account enumeration as a service. If you know someone’s email address you can often easily determine if they have an account somewhere using WebFinger.
Well RFC 5785 explicitly only allow /.well-known at the top-level of the path (see https://tools.ietf.org/html/rfc5785#appendix-B). This was enforced when OIDC discovery was re-published by the IETF as RFC 8414 - in OIDC you simply concatenate /.well-known/... onto the end of an existing URI. In the OAuth RFC version it has to replace the path component.
But how does the RP know when to stop going up the hierarchy? Presumably it shouldn’t look under .com or .co.uk? If the user’s site is at foobar.github.io should it also look under github.io? That crosses a security boundary because github.io is in the Public Suffix List (https://publicsuffix.org/). I may not want GitHub to handle logins for my own site. So does the RP need to consult the PSL?