11436 SSO

OAuth 2.0: Don’t Throw the Baby Out with the Bathwater (Webcast Q&A)

Gregory Brail
Aug 16, 2012


Thanks to all for your interest and participation in our OAuth 2.0: Don't Throw the Baby Out with the Bathwater Webcast on August 2nd. You'll find the video and slides here.

There were several questions that we didn't get a chance to address in the hour so we'll follow up on them here. And we'd love to continue the conversation over on the API Craft Google group.

What's the best practice for using an API to CREATE a user account (username and password)?

In general I think that creating a user account for anything “real” without stuff like a CAPTCHA (to prevent bots) and e-mail validation can lead to other problems like the possibility of someone overwhelming your sign-up infrastructure. But if it makes sense to your business to create user accounts without that, then a simple API call that authenticates the application (aka it is “one-legged”), lets the user select a password and enter an email address, and follows up with an email validation could certainly work.

How to keep the access token in a browser to make JavaScript calls to an API. Should they be encrypted?

To a certain point, you can’t. Anyone with a decent web debugger (or Chrome for that matter) can see everything that their browser is sending and receiving and all the script logic, and anyone on the Internet can download all your scripts and see what they do. So you need to make sure that you don’t store that token anywhere like on the disk (which you basically can’t do in JavaScript anyway as far as I know) and that you set a reasonable expiration time for that token.

It is safe to use OAuth2 if you are not using SSL?

No. Right now bearer tokens are the only mature standards out there for access tokens and they must be secured using SSL on every API call. Furthermore (and more importantly) even if you end up using another type of token, all the authorization flows to actually get the token have to be encrypted as well.

If you expire tokens, what are some drivers for choosing the expiration?

I think that’s a great question for whoever is your local security policy expert, but in general if you are not using refresh tokens, then you have to balance how often you want to re-authenticate the user using a password against how much you trust the various applications that store the token locally. If you trust a particular application to store the token very carefully, or if you prioritize user experience over the possibility that a token can be ripped off someone’s device or web server, then long expiration times are good. In the field we have seen everything from 15 minutes (which makes things pretty unusable IMHO) to a year.

Are there even any alternatives to OAuth that have real potential viability in the next few years?

I haven’t seen any. The basic OAuth 2.0 framework is being extended to support things like JWT and SAML and is the basis of OpenID Connect so things are going pretty far.

What would be the best scenario to externalize the authentication and access token grant from the relying party? By using an sts for example?

I’m not sure if this exactly answers your question but our customers use a third-party API proxy to mediate API access and verify access tokens. (Obviously, because that’s what our product does!) The proxy can also handle the granting of access tokens and all the various grant types, or it can delegate that to a third-party. Ping Identity is one company that’s doing that that we’ve integrated with.

Can a GUID be used as a token?

There are a bunch of types of UUIDs/GUIDs. Some are 128-bit, securely-generated pseudo-random numbers, and those make great bearer tokens. Other types are mainly timestamps, some sort of node id (they used to have the actual MAC address of your machine before a big security scare) and a small random component and they would not be good. For instance, I know that java.util.UUID.randomUUID()makes a good one in Java but I don’t know about other implementations.

If implementing a new OAuth 2.0 API, should you just jump to the latest draft version or fall back a few to a more commonly used one? I think now that the OAuth 2.0 framework and bearer token spec are “Proposed Standards” then it’s time for everyone to use the current version and start to upgrade.

Wondering if Apigee has also implemented OpenID (not OpenID connect) as part of its product offering?

We have a few customers who use it but it’s not generally part of what lots of our customers do.

When asked if you know about OAuth alternatives being mature soon you said no. Who were you thinking of as alternatives?

I am not aware of viable alternatives but I’d love to hear about them.

If SAML assertion is accepted can OAuth be configured that form of authentication/trust?

My understanding of the SAML spec for OAuth is that it extends the spec to add a new grant type. So rather than using a username / password to get an access token, or redirecting the web browser, the authorization server verifies a SAML assertion.

How can OAuth2 be "in use" if it is not yet final? Isn't that part of the problem?

I think that Facebook and the other companies who adopted earlier drafts of 2.0 were trying to solve a usability problem that they saw with OAuth 1.0 and they also saw that OAuth 2.0 solved a real problem that they needed to fix ASAP to make their APIs vulnerable, and in doing that they did what they needed to do. I agree that it added some confusion to the world of OAuth 2.0 but I think that’s better than ignoring it, because by now someone else would have invented an alternative. But now that the spec is a Proposed Standard I hope that they will all upgrade. (And if not, then I believe there are a few of us on this webcast who would love to help.)

How do we use OAuth2.0 in service-to-sevice context (without browser)?

You can use the “resource owner password credentials grant type” in which you simply exchange a username and password for a token. This has some advantages because the server can still distinguish between different client applications and devices. You can also use the “client credentials” grant type which just exchanges app credentials for a token.

Why is it called a Bearer Token?

A bearer token grants the bearer some privilege. It is like a "ticket to ride." A "boarding pass" after you have passed through airport security. It will get you on the plane. If someone swipes your boarding pass, they can get on the plane in your place. (Thanks, Dino Chiesa for the answer.)

Could the panelists discuss alternative/competing mechanisms? For example, what's the difference between OAuth & OpenID?

OpenID is an earlier spec that used an OAuth-like mechanism to perform browser single-sign-on. OpenID Connect is the newer version which is actually built on top of OAuth 2.0, and adds extensions and additional data to make it into a single-sign-on mechanism as well.

How does OAuth solve the authorization problem?

The access token, once granted, uniquely identifies the user, application, and client device that is being used. It also comes with an optional “scope” which allows the client to ask to get permission to do certain things. The server’s job is to verify the scope against each API call to see if the client is authorized.

How is the token protected?

On the wire, using SSL. On the server, it can be hashed. On the client, you have no choice but to be careful with it and encrypt it if you can.  

What about "internal" applications where the user has "already been authenticated"? All the existing 3-legged are too much, the 2-legged doesn't provide a User parameter. What do others do for this case?

The nice thing about the OAuth flows that use a browser redirect is that it is up to the authorization server how to authenticate the user. For instance, if the user is already logged in and has a cookie, then the server can simply let the user proceed.

What is a good expiration time for an access token?

A common expiration time is 3,600 seconds (1 hour) (from Aaron DeGroff ) Yes, an hour seems to be common, sometimes a day can work, and less than an hour is out there but IMHO makes it hard to use stuff.

Is there any open source OAuth2.0 framework available for Java applications?

I have seen Spring Security and I believe that there are many others.

Does Spec Revision mean the Authorization Framework?


Are there any scenarios with central authentication application (STS)?

Yes–the spec allows the “authorization server” which handles the granting of tokens to be separate from the server that validates the incoming access tokens.

How do I secure my REST API using OAuth 2.0?

There are some open-source frameworks out there, and of course one option is to use a product like Apigee to do it for you.

Are there compelling reasons to switch to OAuth 2.0 if you currently use OAuth 1.0a?

From our own experience, and what we see out in the public API market, a large amount of the pain and suffering that some API users go through has to do with generating OAuth 1.0 signatures. They are a big stumbling block for lots of developers—they generally find bearer tokens to be a lot easier to deal with. So yes, I think it makes sense to switch.

It is safe to use OAuth 2.0 if you are not using SSL?

I think that we answered this.

But you could use HTTP-mac without SSL, right?

The spec is very old, doesn’t seem to be moving through the IETF process, and is rarely implemented. You can certainly use it but you might be in the minority, at least unless someone gets involved in the IETF and starts to push it forward.

What about trusted internal clients for which you want to know about the end user that was authenticated via some other SSO method?

As we said above, the grant types that use a web browser redirect can simply re-use existing credentials if they’re present in the browser. Also the SAML and JWT grant types are designed to handle these kinds of scenarios too.

Do you guys think it makes sense to protect the account creation API call with the client credentials flow?

I think you could do that (referring to the very first question). You would then at least have control over the various apps that can create users and you can rate-limit them or shut them down if necessary.

Scaling Microservices