Two Legs Good? “Client-Server” OAUTH Usage

Session Topic: Two Legs Good? “Client-Server” OAUTH Usage (W4G)

Convener: Eve Maler

Notes-taker(s): Mark Atwood, Eve Maler

Tags for the session - technology discussed/ideas considered:

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

It is noticed that OAuth is being used for internal services. It's not being talked about much publicly. What are the good/best/bad practices for doing it?



What is the terminology?  "2-legged" vs "client/server"? Though most people detest "2-legged" and "3-legged", they also understand what it means.

2L is being used to replace sending dev API keys across the wire with every request. You can use the signing mechanisms in OAuth 1, or with OAuth 2 you can use the client credentials flow. When using the client credentials flow, using refresh tokens doesn't make sense (SalesForce explicitly disallows it). Usually an access token is considered to be the length of a "session", but this doesn't have meaning in the 2L context. What does "expiration" really mean in 2L flows? In Justin's implementation, the client is brain-dead; it just keeps trying until it gets a 200 OK. We don't want people to think of "cookies".



There are use cases where apps want do to both SAML and OAuth into a service. This still has a user in the mix, but it's still an implicit grant. A 2L authorization grant is implicit in a deeper way; the client represents itself.



(OAuth 1 forced you into a long grant in order to get anything done. Refresh tokens in OAuth 2 are only good for getting access tokens, so they're safer.)



Torsten has a token revocation draft that lets you submit the token and say "cancel this", but it doesn't have things quite right yet. SalesForce and others are planning to use this revocation model.

There are enterprise customers for whom the term "OpenID" and "OAuth" are negative statements; the words must be avoided. But one customer has a REST API protected by OAuth 1.0a. In that case, they use admin-configured tokens. A defect tracking system needs to be registered across the system against code changes. For a test org and a dev org that are in different identity domains inside an enterprise, they had to tinker with OAuth 1.0a to include user ID and group info.



Removing query string tokens from OAuth 2.0 breaks shipping a signed URL.



Info security control is a mirage. People WILL use Gmail, Dropbox, and Evernote to get their work done. When IT becomes non-innovative because it is the one monitoring, the business units will become innovative because they have to get work done.



Internal use of OAuth is useful for reducing dependency on a central authorization server.



A few SalesForce customers ask for 2L flows in the context of federating for web operations. The user at the customer site has gone through a SAML service, and SSOs into SalesForce. Or, TripIt or Concur wants to connect an app to SFDC's social network, to post someone's flight schedule to people in your network. For Concur itself to tell Chuck that his flight schedule has been updated, the message is literally coming from Concur, so 2L could be used for that. That flow can be preconfigured to have certain permissions. The SAML token would contain the subject.



Google Apps Marketplace has an admin doing the scoped grant at install time, rather than having the user do this at one-time.



One company had a blog service and a picture-storing service that used the OAuth flow. This was in the context of users, but they didn't want the authorization screen to come up between these two services because they were run by the same company. SalesForce has the same thing: If a user tries to connect with an OAuth client that was defined inside the same tenant (company) in the system, the implicit flow is used.



MITRE has a social networking site called Handshake, outside its firewall, along with recommendation services etc.. The service can be used by both MITRE and external people. It's based on a collaborative tool called Elgg. Different data sources contribute to it. For people on the outside, a user agent using the recommendation engine can easily get access to stuff stored outside.  The internal recommendation engine shouldn't need to know much about users. So the internal recommendation engine and the external Handshake platform have something like 2L OAuth, and all user-specific authorization decisions are being made by Handshake. Handshake is generating a signed ID, and the internal recommendation engine just has to validate the key and secret. This uses OAuth 1.0 2L, signing the full URL, with no token.



Now that OAuth 2 forces everything to be in authorization headers, they can't use the MAC token profile. This will prevent OAuth 2 from being used widely for this purpose. But they will be switching to client credentials and short-lived tokens for some other use cases.



Net-puncturing in general is done with a trick like Alan Karp used for his "SCOOPS" demo. InfoSec wants control, and when they put up controls, people work around them. It's so much easier to set up services than to even know how to get permission for them. At one company they're allowed to blog and tweet, but they have to go through social media training, and at the risk of being terminated (everything is being monitored), they comply. Alan: "There is another way not to get fired, which is to get your job done." :-)



Before OAuth, client apps just used a username and password, which is ideally different for each client app but often not.



Some companies have so many loosely coupled apps internally that 2L OAuth is used as a cleaner alternative than a centralized authorization server. It takes away a dependency on a centralized server, so it can't bring your apps down.



Another benefit of OAuth is the constrained delegation: read-only vs. read/write tokens, for example.



AOL has also used OAuth instead of IP ACLs. If only certain sites are supposed to access a certain API, it's nice and clean. It's also good for signing URLs that have redirects in them, to constrain the system from doing open redirects.