[OAUTH-WG] Re: Feedback on draft-jenkins-oauth-public-00

[Lisa Dusseault <[e-mail]>]

Yes, and:  protocol names should be part of the scope names, but I can
imagine so many use cases for finer-grained access.  Many clients might
want read-only access to something like calendar or email data, and the
user might find it safer to grant read-only access than full access. As
always, there's a tradeoff between options and complexity!

The OAuth resource metadata approach does not work for feature
advertisement in the non-HTTP server use cases.  There are still mail
servers that don't support HTTP!  CalDAV, however, it would work fine for.

Lisa

On Thu, Jul 25, 2024 at 11:18 PM Emelia Smith <emelia=
[e-mail]> wrote:

> Hi Neil,
>
> I mentioned in the zulip chat that I rather like the idea of using
> protocol names as scopes, but that maybe you'd want them to be finer
> grained.
>
> On second pass, I'm wondering if it'd make sense to expose a list of
> supported resources & protocols for the authorization server, not just
> relying on scopes?
>
> Maybe through using Protected Resources Metadata?
> https://www.ietf.org/archive/id/draft-ietf-oauth-resource-metadata-07.html
>
> Yours,
> Emelia
>
> On 26. Jul 2024, at 07:48, Neil Jenkins <neilj=
> [e-mail]> wrote:
>
> 
> Hi George,
>
> Thanks for the feedback.
>
> Section 1.1
> * is there a reason that only email address based login identifiers are
> supported? It seems like this profile could be used for other use cases as
> well.
>
>
> No, this should just be username. (It is of course likely to be an email
> address, but you're right: there's no reason it has to be for the purposes
> of this document.)
>
> Section 1.2
> * I would recommend this document be more generic and then a specific
> profile for say IMAP can be defined that then also defines the scopes
> required for use with an IMAP server.
> * This document can just say that scopes required are out of scope (pun
> intended)
>
>
> As mentioned at the IETF meeting this week, it's definitely an open
> question whether scopes should be part of this document or a separate one.
> I can certainly see an advantage to leaving it out of this profile and then
> having another document that pulls it all together (referencing an
> autodiscovery RFC, OAuth profile RFC, and listing the scopes).
>
> Section 2.1
> * Recommend changing the last sentence to... The rest of this document
> describes in detail each of the above steps.
>
>
> Sure, that reads better.
>
> Section 2.2
> * I recognize that Security Considerations will be filled out in a future
> version. A topic that needs to be present is the potential implications of
> proceeding with the flow when not all the required metadata fields are
> present. I suspect most authorization servers do not have a
> 'registration_endpoint' URL in their metadata configuration :)
>
>
> If the server's metadata doesn't conform to this profile, then clients
> supporting the profile are likely to abort. The point of this profile is to
> say "if you implement this as a client you will be able to authenticate
> with any server that implements this" and vice versa. If you don't
> implement it, you're not following the profile, and there is no
> interoperability guaranteed.
>
> * Can you clarify why the 'token_endpoint_auth_methods_supported' MUST
> include "none"? If the client is dynamically registering, then it can
> receive it's own instance specific client_id and client_secret which allows
> it to authenticate to the token endpoint. Not requiring client
> authentication seems dangerous.
> * Similar comment for 'revocation_endpoint_auth_methods_supported'
>
>
> We made this none, because the RFC7591
> <https://www.rfc-editor.org/rfc/rfc7591> refers to the client secret as
> only "used by confidential clients", which open native clients running on
> the user's machine are not. I guess my main question is what does this gain
> us? I would rather reduce options wherever possible to increase
> interoperability and security while keeping complexity to a minimum. If we
> presume there is no security difference in how the client stores the
> refresh token and any client secret, what does the client secret add in
> this case?
>
> Section 2.3
> * I do not think the developer should be able to do the registration.
> Instead, this should be required to be completed by the client. This will
> be the expectation of the Authorization Server if it supports Dynamic
> Client Registration.
>
>
> Agreed.
>
> * There are security implication with using a custom scheme. Best practice
> for mobile apps is to use claimed URIs rather than custom schemes. If
> custom schemes are the only option in certain cases the risk need to be
> clearly called out in the Security Considerations section.
>
>
> This profile is intended for native apps only, which is enforced by only
> allowing localhost or private-use schemes for the redirect_uri. Being
> able to dynamically register like this to do the OAuth flow would make it
> too easy for a phishing site to get the user to grant them access to their
> mail/contacts/calendars etc. — with a native app, it could already fake a
> browser window and phish the user undetectably, so we're not making the
> security situation worse. If the user's downloaded something malicious,
> they've already lost.
>
> * I'm strongly against allowing the 'token_endpoint_auth_method' to be
> "none". There is no reason that the default of 'client_secret_basic' can't
> be used (as far as I understand the profile). I recommend that the
> registration response from the Authorization Server also include a
> 'client_secret'. The client can then store the secret appropriately on the
> device. This secret is instance specific and hence the device must be
> compromised to extract that secret and impersonate the user.
>
> Section 2.5
> * I believe the client should authenticate itself via some mechanism and
> not just present the client_id
>
>
> As above, I'm happy to change this if there's a security advantage. I'm
> just trying to understand why the client would be able to store the client
> secret securely but not the refresh token (which is also needed to
> impersonate the user). And if it can store both the same, how the client
> secret adds any extra security?
>
> Cheers,
> Neil.
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>
> _______________________________________________
> OAuth mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>