The approval screen is a detail of the UX that the protocol itself
doesn't address, since there are several instances where an approval
screen does and does not make sense.
If you're doing a "trust on first use" (TOFU) scenario where the
resource owner is the same as the end user (remember, they may be
different entities entirely!), then the approval screen is very
important. This is the classical OAuth use case, and one of the primary
novel things that it allows for which other protocols don't. Since most
of the publicly-facing deployments of OAuth are in this kind of world,
where you're using the end user to bridge trusted security boundaries
via OAuth, then you see a lot of this.
If your end user and resource owner are different entities, then the
person sitting at the browser might not actually have a choice about
whether to allow access. In this case, it doesn't make any sense to ask
them because the decision is being made by policy, or by circumstances
around the request. It does still make sense to do a three-legged OAuth
in this flow, because you can then bind the context of the user having
authenticated to the AS in the front channel with the client having
authenticated to the AS in the back channel. This separating and
re-binding gives you three legs in an authorization triangle, which is a
very powerful and secure pattern to follow. We're starting to see things
like this in the enterprise world around OAuth. Instead of using an
all-powerful tight binding credential between systems, you've got a
whitelisted OAuth client. As far as the client knows, it's doing vanilla
OAuth and the world is all as it should be. This is a very good (and
somewhat novel) thing for enterprise systems.
But even in the TOFU scenario, it's important to let the user say
"remember this decision in the future and don't bug me about it". In
this case, the server remembers the authorization grant decision that
was previously made by the resource owner and doesn't prompt the user.
Most OpenID 2.0 setups do this already, and some OAuth setups do as
well. I think Google does this, I know we're building it in to our
projects, and I think we'll see more of this functionality going forward.
-- Justin
On 08/03/2012 03:07 AM, Jérôme LELEU wrote:
Hi,
In the OAuth 2.0 spec, I don't see any mention of the "Allow /
disallow" screen (just after the user is logged in). However, most of
the OAuth providers I know (Facebook, Google, Twitter...) have such a
"allow / disallow" screen.
Did I miss something in the spec ?
What are the security concerns about not having such "Allow /
disallow" screen ?
Thanks.
Best regards,
Jérôme
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
