Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Do you have any pointers on how one should go about implementing the oAuth2 protocol itself? That is, the server side or the "provider" facet of OAuth2?

If you have tried to implement (a part of) it, please share the issues and the solutions. Note that this is completely technology and programming language agnostic - except, of course, for the de-facto standard cryptological technologies that might be involved. The IETF draft (v23) for oAuth2 is located here

share|improve this question

2 Answers 2

While I have not yet implemented it I do intend to and have read through both the OAuth 1 RFC and OAuth 2 draft several times. Unlike OAuth 1 RFC the OAuth 2 draft goes into quite a lot of detail as to how to implement the server and you will find all the details you need in the draft.

What you will need to first figure out is your target group of clients since that will help you decide which methods of authorization you need to support.

Web apps? Check out http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.1

JS apps? http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.2

Desktop apps? http://tools.ietf.org/html/draft-ietf-oauth-v2-23#section-4.3 (if the user will trust your app with their credentials)

The protocol basically boils down to generating tokens using adequate crypto functions and encoding and sending parameters properly. For an example of how the communication might look like go to the Google OAuth 2 Playground.

For example, the draft clearly states that when a client requests authorization as per 4.1 (Authorization Code Grant) it supplies the mandatory fields response_type and client_id together with the two optional fields redirect_uri and scope, as well as the recommended state field. In your server implementation you thus extract and validate those parameters (you may define additional required parameters), authorize the user and if all is well redirect to the client specified redirect uri (including an authorization grant).

How you authenticate clients can vary but the spec suggests that using HTTP Authentication would work fine for web apps (but not apps where hiding the client credentials is difficult).

It is very important that all communication is over a secure channel (TLS/SSL). OAuth is not a substitute for TLS/SSL.

Good luck!

share|improve this answer

OAuth 2 does not have much in the way of cryptography requirements. It relies more on the communications being over secure channels. We have implemented a full-fledged OAuth 2 service (http://www.assurebridge.com/our-products/mobileconnect/) and found that the most complex parts are the authentication (before issuing the token) and the verification of an incoming token. Both of these are not actually part the the spec so you need a tremendous amount of flexibility here.

The other issue is state. Since the OAuth server needs to remember the token, it must maintaining all current, non-expired tokens. To be fault tolerant you need to look into a distributed session store like jcache or nCache.

Since there is back channel communication and verification, you also need a good http client library as well as JSON.

The other area we faced was performance. Since every request from a client application to an application service requires a access token and that access token needs to be verified with the security service, this generated a lot of traffic. We implemented a caching scheme to cut down on the back and forth making sure the cache timed out before the tokens expired.

I agree, the Google implementations are a good place to start since they have become a de-facto standard.

Good luck!

Oleg

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.