Link to example application?

[philips]

Awesome work on this Lincoln. I wrote a quick example app to show that everything is working if you want to link to it:

https://github.com/philips/endpoint-hello

/cc @crhym3

[x1ddos]

nice! @rwl I'd love to make go-endpoints be compatible with rwl/endpoint. I had a quick look at your forked version of go-endpoints. Do you think it would be feasible to merge so that both (w/ and w/o App Engine) versions can coexist?

[rwl]

I removed all of the App Engine dependencies in my branch of go-endpoints. This included the authentication features based on the Users API.

I wanted to create an authentication interface that could have multiple implementations, including App Engine, but didn't get very far. If you have any suggestions on how to do this I would be very interested to hear them. I suspect restricting it to OAuth would make it easier.

[rwl]

I added a link to your Greetings example in the readme.

[x1ddos]

Yeah, specifically OAuth 2.
The auth verifications are currently invoked from within public CurrentUser method, and based on the supplied Authorization header (by the client making a request), looking for either bearer=<token bits go here> or oauth=<token bits go here>.

Once we've got auth data, it tries to validate as if it were a JWT token first- it's cheaper and faster. BTW, they also call it ID token sometimes. If that fails, it falls back to the "standard" bearer token validation. Both validations obviously check for scope, audience and clientId matching.

The validation mechanisms are really standard and have nothing to do with App Engine and its Users auth service. The only bits that are specific to Google, i.e. Google Accounts and have nothing to do with App Engine - and they will be different for every OAuth 2.0 provider - are the following:

• for JWT token validation you'll need a provider public certs. Google publishes them at this URL. I wanted to find you the same info for Facebook as an example but it looks like they don't support JWT tokens yet (couldn't find any info on dev site docs).
• for bearer token validation you'll need an URL supplied by the provider at which they can reply to you whether that token is valid. For Google it's https://www.googleapis.com/oauth2/v1/tokeninfo. For Facebook it must be graph.facebook.com/debug_token - found it in Inspecting auth tokens section.

So, it really looks like it's a matter of gathering JWT/bearer token validation info for different providers and making it work across all of them: I'd probably expect some differences in implementations.

Closer to the code, I was thinking about something like endpoints.AddAuthProvider(...) method which users can invoke in an init function, after or before they register their services/API handlers. This would allow anyone to implement a custom auth verification, not even necessarily OAuth.

What do you think, makes sense?

[rwl]

One other thing I had to remove was the Context code. This seems to be App Engine specific. Embedding the App Engine context and being passed when calling a Data Store query. Should the Context be retained and still used to get the current User?

One thing I like about the Java implementation of Endpoints is that if your RPC method has a User argument then it requires authentication and the user argument is populated with the result. It looks as if a replacement for the appengine.User type is required. Perhaps if this were an interface and if the request argument to a RPC method implicitly implemented it then authentication would be invoked.

Your endpoints.AddAuthProvider approach sounds good. I wouldn't mind if only a Google provider, the details for which we already have, was provided to start with. So long as we can eliminate the App Engine dependencies and create a generic interface that can be implemented for other providers in the future.

[rwl]

I am beginning to understand you explanation of the token validation procedure @crhym3. I have added three Provider interfaces.

So far, I have gathered info for Facebook, Github and Amazon. I would like to include an OSIN provider eventually also.

Can you have a quick look and let me know if my approach is in line with how you imagined it. It would be great to get this merged into your repo eventually.