OAuth Login for Enterprise

Question

I am designing the architecture for an Enterprise SaaS application and wanted to know if there is a disadvantage to only providing an OAuth type of login. This is not a third party authentication server, we will be in control of it. My only worry is that people will not like the "Accept Permissions" page that is part of the whole OAuth2 authentication/authorization flow. They will still be able to create an account for their given tenant or have an account created for them by an administrator.

The current flow to log in is:

Sign In:

Authorize:

I am using Cloud Foundry's UAA OAuth2 Server for the backend. Thanks for any guidance.

Answer 1

I agree that (some subset of) people will not like that extra authentication screen, because from their perspective it serves no purpose at all.

This is not a third party authentication server, we will be in control of it.

Then there is no point in disguising what is actually a first-party authentication process as a third-party OAuth scheme; all that accomplishes is interposing an unnecessary extra form for the user to click through before completing their login.

There are different types of OAuth workflow; you're trying to use the wrong one for your particular circumstances.

The workflow you're using (the "Authorization Code" grant type) is meant to allow the user to take an existing authentication token from site Foo, and use it on site Bar. The extra "authorization" page serves to prevent phishing attacks by notifying the user that the authorization (though not the password itself) is being shared from Foo to Bar, so they can confirm that Bar is in fact who they wanted it shared with.

In your case, Foo and Bar are the same site. The user wants to log into your site, you're routing them through an OAuth scheme in which their only meaningful option is to confirm that when they typed their login information into your site they intended to actually log into your site. Which is, you know, silly.

For this circumstance what you want is the "Password Credentials" OAuth grant type. In this workflow the extra confirmation step is unnecessary, because there is no third party to share the authorization with. The user interface is familiar: they're on your site, they enter their username and password, they're logged in. The user doesn't need to be aware that the underlying authentication scheme is OAuth-based.

(Anecdotally: a substantial percentage of users still don't quite understand OAuth; in every site I've worked on that uses it, it's been a persistent low-grade source of user confusion. Common, recognizable authentication providers ("Log in using Facebook" or "Log in using Twitter") seem to cause less confusion -- enough users will have encountered that on other sites that they'll understand what it means on yours. Smaller, more obscure providers tend to be much more problematic (expect support tickets along the lines of "Hey, I was trying to log into your site but somehow wound up on something called Cloud Foundry! I think you've been hacked!!")

(The larger providers are also much more convenient in practical terms for the end user: most will have a Facebook or Twitter login token in place and ready to use; that will not be the case for Cloud Foundry.)

Answer 2

Don't worry, most users like the feeling that they are in total control of access permissions inside an application (unbacked claim alert). The Authorization screen will give them an extra chance to think about their decision.