0

I've read through RFC 6749: https://datatracker.ietf.org/doc/html/rfc6749

The only mention of consent is in this bit:

The authorization server MUST implement CSRF protection for its
authorization endpoint and ensure that a malicious client cannot
obtain authorization without the awareness and explicit consent of
the resource owner.

The above does not (to me anyway) translate to: "Hey show a consent screen with requested scopes before responding with an authorisation".

I've seen so many OAuth 2.0 implementations however where a consent screen is shown.

Question 1: As per the title really - is it actually needed?

Question 2: Is there an RFC that specifies what such a consent screen (if you are to implement one) should look like, including any required messaging and response if the user declines?

Ash
  • 111
  • 6
  • I've checked RFC 7591 (OAuth 2.0 Dynamic Client Registration Protocol) and there's no mention of "consent" there either. – Ash Jul 24 '21 at 11:19
  • After some thorough Googling, I was able to find a similar question/answer here: https://stackoverflow.com/q/47738457 – Ash Jul 24 '21 at 11:24

2 Answers2

1

The consent screen is not part of the oAuth standards, but are often the result of other rules / laws. (Such as the GDPR)

Especially since with oAuth we can switch “privacy context” where we should let people be aware of it that and give permissions / options on what to share.

LvB
  • 8,217
  • 1
  • 26
  • 43
  • Thanks for that. Could you elaborate a bit on what you mean by "switch privacy context"? – Ash Jul 25 '21 at 23:40
  • Like if you switch from Google to your site, those are 2 different “privacy context” (might be a better term for it but I think it fits well) – LvB Jul 25 '21 at 23:42
0

The consent screen is not only required by law. It is implicitly assumed by the spec but not explicitly mentioned. This is why almost all OAuth authorization servers show some form of consent.

Let’s take a step back: OAuth is about granting a third party access to resources the owner of a resource owns. In most cases the resource owner is a human being an thus needs to be informed what is going on.

Typically, this includes information about the client (as it is a third party) and the granted resources. The user also has the option to change the requested scope of the authorization granted to the client:

The authorization server MAY fully or partially ignore the scope requested by the client, based on the authorization server policy or the resource owner's instructions.

(RFC 6749, Section 3.3)

Maybe the original OAuth 2.0 standard should have payed more attention on explicitly describing the consent. A indication for this might be that consent is mentioned more often in the current draft for OAuth 2.1. Some examples:

Before directing the resource owner back to the client with the authorization code, the authorization server authenticates the resource owner, and may request the resource owner's consent or otherwise inform them of the client's request.

(The OAuth 2.1 Authorization Framework, Draft 04, Section 1.3.1)

In typical web-view-based implementations of embedded user agents, the host application can record every keystroke entered in the login form to capture usernames and passwords, automatically submit forms to bypass user consent, and copy session cookies and use them to perform authenticated actions as the user.

(The OAuth 2.1 Authorization Framework, Draft 04, Section 7.20)

JuliusPC
  • 101
  • 3
  • I see. There appears to be a reference to it in the spec for 2.1 but certainly not 2.0. – Ash Dec 30 '21 at 10:44