I am evaluating the possible options provided by Google for adding google signin in my web application. The possible options as i see are
Google+ Signin
OAuth2.0
OpenID Connect ( OAuth2.0 for Login )
I didnt go with 1st one as it limits the API calls i can make in a day to 10000
Out of 2 & 3, i am inclined to go for 3rd. I dont really need API authorization and i am not concerned about access token expiration in my case. Once i receive user profile from Google, my web app will manage its own session of the user and does not need to query Google for any other data related to the user. And as per Google documentation, #3 allows me to customize User consent screen, while 1 & 2 dont.
Any comments on my comparison between 2 & 3 ?
In fact 2. is comprised of a Google specific usage/extension of OAuth 2.0 to establish user identity on top of the authorization provided by core OAuth 2.0. Using 2. you would have to ensure that you only receive the access token in a code flow and you would have to perform a Google specific introspection call to find out who the user is, where the user's identity is returned in Google specific claims.
On the other hand,3. is a standardized way to login users through a 3rd-party provider so it is a future safe choice for which you'll find more support in libraries/sdk's (well at least in the near future).
Related
I'm having difficulties finding documentation for auth0 and microsoft graph integration. My end goal is to have a SPA that can login with a microsoft profile to auth0 (connected to azure ad). Then I want my app to get a token for microsoft graph and do some api calls.
As I've understood it so far, auth0 does not allow you to get the access token to different identity providers in a front end application, but rather that they should use a proxy to get this token. My flow therefore is:
I login with a SPA auth0 app (using a microsoft identity)
This is then used to authenticate to a backend server using a api registration in auth0
The backend has its seperate machine-to-machine app in auth0
Backend api uses this seperate app to get access token to auth0 management api
Current user is fetched (based on the logged in user from front end app login) from management api,
Here i find an access token under the azure identity (if I do the same in the front end, the access tokens are omitted)
Token does not work to call graph, I am unsure of where to send it next.
I am aware that the above is probably completely wrong, that's why I am here :)
My questions are:
1) Is it even possible to get an access token for microsoft graph starting from a login to auth0 in the way I want it to. If not, can it be done from a backend?
2) Does anyone have a link that discusses this, ideally with some code samples.
To answer your first question:
1) Is it even possible to get an access token for microsoft graph starting from a login to auth0 in the way I want it to. If not, can it be done from a backend?
I have had the chance to authenticate apps using the microsoft identity library called MSAl whose documentation is found here. It gives a pretty detailed way to authenticate directly from your SPA.
I have also used the microsoft javascript sdk as it comes inbuilt with token caching and refreshing so that I do not need to build that for myself.
In relation to this,
Does anyone have a link that discusses this, ideally with some code samples.
You can find the samples well described in the samples section of the SDK
I hope this helps.
After reading the documents of Google API. I know that if a project we create needs to access private data, we should use oauth. But here is my situation. we will open a business account in Youtube, and we will create a project to push videos to our own account, we don't need to operate other user's' account. Can we use google youtube data api without OAuth?
There are two ways to access private user data with Google APIs.
Strait Oauth2. where you have a consent for asking the owner of the account if you can access it
Service accounts which are technically pre authorized by the developer.
Normally I would say because you are only accessing the one account that you own, use a service account. Unfortunately the YouTube API does not support service account authentication.
Due to the lack of service account support you will have to use Oauth2. I have done this in the past.
Authentication your script once, using a server sided language of some kind. The Authentication server will return to you a Refresh token. Refresh tokens can be used at any time to get a new access token. Access tokens are used to access Google APIs and are only valid for an hour. Save this refresh token someplace. You will then be able to allow access the YouTube account in question when ever you like.
Note: You will have to watch it. Refresh tokens can on rare occasion become invalid. I recommend having a script ready that will allow you to re authenticate the application again storing a new refresh token. Its rare that it happens but it can happen best to be pre-paired.
Oauth Play ground
Part of the point of Oauth is that it identifies your application to Google though the creation of your project on Google developer console. Things like quota and access to which APIs is controlled though that. If you spam the API they will know and shut you down. (never seen this happen)
When you request access of a user it pops up with the name of the project on google developer console. This is identified by the client id and client secrete for that project on google developer console. When I use oauth playground I get asked 'Google OAuth 2.0 Playground would like to ..'
So by using playground you are using Googles client id and client secrete to create a refresh token for yourself. If N other devs are also doing this the quota for YouTube may be used up in the course of a day. Also security wise you are now giving that project access to your data. Ignore that for a second what if google suddenly decides to remove change the client id or generate a new one. Your refresh token will no longer work. What if random dev X is using it as well and he starts spamming everything and the client id gets shut down (Think this happened last year) your going to have to wait for google to upload a new client id for the one that has now been banned.
Google OAuth 2.0 Playground might seam nice but its not for daily use IMO its good for testing nothing more. Create your own project and get your own access its not hard just requires a programing language that can handle a http Post.
My tutorial Google 3 legged oauth2 flow
So I read the following on the Authorizing Requests to the Google Calendar API page written by Google folks.
Your application must use OAuth 2.0 to authorize requests. No other authorization protocols are supported. If your application uses Google Sign-In, some aspects of authorization are handled for you.
My knowledge of OAuth 2.0 is limited so I'm not sure if that means that I cannot get a one-time auth token for a user?
I'm building an app that will need to CRUD events for a user in the background based on other stuff. So I can't have the user authenticate over and over again. Is there a way around here?
If not, is there an Google Calendar alternative that has a dependable API that I could use?
When the user authenticates your application you are given an Access token (good for one hour) and a refresh token. You should save the refresh token, when ever you need to access the users data you can take the refresh token and ask Google to give you a new access token. It is the access token which gives you access to there account.
I wrote a tutorial that tries to explain Oauth2 how to set it up and how it works. Google Developer console Oauth2
I'm trying to authenticate my user on my site using StackExchange OAuth API.
Everything works fine when the user signs up for the first time. At this point, I get the "access token", which I save in my DB.
But the next time the user signs in, access token value is actually different to the previous one. Is it supposed to be like this?
If then, how do I check for existing users who already have signed up using StackExchange?
I can get the user's information by giving a specific site name (e.g. 'stackoverflow'). But what if I don't have that information and I need to check that the user has already signed in via StackExchange?
Is there a "user" information that I can get given an accessToken?
The StackExchange OAuth implementation is not meant to authenticate users to 3rd party applications but instead it is about authorizing those 3rd party applications to get access to the StackExchange API.
The access token that you get is not a token that represents a currently logged-in user, it represents the permission to access the API on behalf of the user gave it to your application. This is the classical confusion about the scope of OAuth 2.0 which is discussed in detail here: http://oauth.net/articles/authentication/.
In summary: you can't use OAuth or the StackExchange access token to authenticate users.
StackExchange does support the OpenID protocol to facilitate the purpose that you are looking for, see https://openid.stackexchange.com/. The downside of that is that OpenID is a deprecated protocol, superseded by OpenID Connect. OpenID Connect is an authentication protocol that is actually built on top of OAuth 2.0, but is not yet supported by StackExchange.
I've just been (re)reading Rob Conery's 2010 blog post OpenID is a Nightmare as part of some research into OpenID/OpenAuth. Ideally, I'm looking to use multiple OAuth providers linked to a single account, to provide resilience against the providers being unavailable - log in with Facebook, link your Twitter and Google accounts, and if next time you visit Facebook login isn't working it doesn't matter, you can use Twitter OR Google to get in and access your stuff - just as, in the real world, you can open a bank account with a passport, and withdraw money later using your driving license if your passport's not available.
One of Rob's primary concerns in his article is that there's no way to consistently identify a user who's using OpenID - somebody might log in with Google one day, buy a product, then come back and log in with Google a few days later and be unable to access the product they bought, because there's no unique identifier that's guaranteed to remain consistent between the two Google authentication calls.
I'm curious as to whether this has been addressed in OAuth 2.0 - either explicitly via the protocol spec, or via some implementation consensus amongst the major providers. Which field - if any - can I rely on not to change for the lifetime of a user's relationship with a particular OAuth provider?
As part of their OAuth2 for login process, Google provide a TokenInfo endpoint that is used to validate and provide information about the access_token that is obtained earlier in the process.
The token information includes userid:
"The value of this field is an immutable identifier for the logged-in user, and may be used when creating and managing user sessions in your application. This identifier is the same regardless of the client_id. This provides the ability to correlate profile information across multiple applications in the same organization."
which sounds like just the ticket (or perhaps token)!
userid is only present if the https://www.googleapis.com/auth/userinfo.profile scope was included in the access token request, so don't forget that.
Similarly, in the Facebook API you have access to the graph API once you've obtained an access token where you can get user data, including ID.
Twitter include the user_id in the access token response as part of their authentication API
If you're using OAuth in a .NET project this might be useful... I discovered today that WebMatrix 2 Beta includes OAuth2 clients for Facebook, Twitter, Windows Live, Google and Yahoo, and can be used from an MVC project. I'm told that you just need the WebMatrix.Security.dll and you're good to go. It's installed into C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v2.0\Assemblies. Although it's in beta and hidden away, it's a good way to get started and might make the the learning curve with the DotNetOpenAuth library a bit less steep.
OAuth 2.0 doesn't solve this - it's not an identity / SSO protocol.
However, OpenID Connect (built on OAuth 2.0) is. You may get lucky and get back the user's email address via OpenID Connect (see here - depending on scopes), or you may get back PPID's which should be unique to a given relying party. Either way - it should be possible.
Alternatively, SAML could be used. It supports many different flavors of user identifiers that would suit.