The OAuth2 PHP client code is awesome. It gives great examples on how to use OAuth 2 with Google APIs. The problem is that I only want to use OAuth 2 for authentication NOT for authorization. I've looked around in the API for something that just authenticates but I can't find the right class.
How do I configure the Google PHP client to only authenticate via OAuth?
I considered just authenticating the client (i.e. `$client->authenticate($_GET['token'])) but that's not ideal because the user is still asked to authorize access to different resources. I don't want to see their email, picture, etc. I just want Google to verify that they are who they say they are.
Well, OAuth is an open standard for authorization and not for authentication!
Most providers however give you the chance to query a users profile, so you can authenticate the user. Without the access to his profile data, especially his user id, you can not achieve this.
See Google's documentation for obtaining the user's profile information for login.
If you only want to use authetication you have to use: OpenID / Federated Login.
See: https://developers.google.com/accounts/docs/OpenID
Related
I'am working on an project where we have a Vue.js Frontend and a Microservices architecture for the backend hosted in Azure Service Fabric.
We wan't to add an IdentityService for authentication using IdentityServer4.
What we want to achieve is a login that is basically the same as stackoverflow provides:
You can login on the website with an embedded login or use external providers like Google and Facebook.
My question only concerns the embedded login.
I have read articles that state using Authorization Code Grant with PKCE is the best way in my scenario. Moreover they say, that Ressource Owner Password Grant should not be used.
But as far as I know, with this flow it is not possible to embed the login to our own website. It will always be a redirect to the IdentityService.
How do Stackoverflow achieve this? Do they use Resource Owner Passwort Grant?
Thank you!
First of all, I welcome you to check how Stackoverflow (SO) handle their user registration process.
SO allows you three options. Login through Google, Facebook or register directly to SO. When someone use Google Or Facebook, SO uses Authorization code flow. User is redirected to respective login page. Once you login there, SO receive user profile details from those identity providers, which allows SO to complete the profile and onboard the user.
But when someone use built in register page, it is simply good old registration page. There is no OAuth involved there. SO obtain end user credentials, complete the profile and save them at their backend.
In your scenario also, you can omit OAuth and use a built in registration or login page. Only concern is the maintenance burden of end user credentials.
We currently have a corporate portal in which users authenticate and get different page views based on their access level. We have been tasked with allowing them to click a Google Mail icon to sign them into their domain Google Mail Account. To do something like this, should we be looking in to oAuth or Open ID? Presently, they're already using their email and password to sign in.
From what we understand, Open ID requires their email and password to go to us, which we have; but will Open ID do what we're looking for?
Thank you.
Since your users have a Google Apps for Business email address already, I would suggest using the Google+ Federated Login feature-set. (You can learn more here: https://developers.google.com/accounts/docs/OpenID)
A quick snippet from the aforementioned link:
If you are planning to provide a “sign-in with Google” feature, we recommend using Google+ Sign-in, which provides the OAuth 2.0 authentication mechanism along with additional access to Google desktop and mobile features...[the] OpenID+OAuth Hybrid protocol lets web developers combine an OpenID request with an OAuth authentication request. This extension is useful for web developers who use both OpenID and OAuth, particularly in that it simplifies the process for users by requesting their approval once instead of twice.
You can find more on the Google+ Federated Login toolset and explore a sample application here: https://developers.google.com/+/
Hope this helps!
I'm gonna try to explain my problem :
I'd like to allow users to connect to my api via their own accounts (login/password) or via a social network (Facebook at first).
Then, I would allow any application to use my api, with the user authenticated.
My first thought when to auth the user via his/her login/password and return a token used as the session for the next requests.
But OAuth would seems to be the better implementations, except I don't know how to do this :
One of my applications will have to connect via login/password, like twitter web (I have to implement an login/password auth somewhere if I wan't my user to login :p)
Will I also have to register my applications to the oauth system (did twitter added their web app to their oauth ?)
How to merge the auth via others social networks. Concretely, the user will have to OAuth to my api that will auth to the social network.
I'm a bit lost on how to do this, if someone could help me, I would really appreciate !
Thanks
Update 1:
Flickr and Lastfm seems to not use OAuth but an alternative auth system that looks like this :
The user is redirected to Flickr/Lastfm
The user auth himself and accept to use the application
Flickr/Lastfm return to the Callback url with a temporary frob (for flickr) or token (for lastfm)
The app must call the provider with the temporary frob/token (among with the api_key and the api_sig, as always) and get in return the session token to use for the next calls.
Update 2:
In fact, StackApps is the concrete case of my problem : you can login through their login/password system OR openId, and you can use their API.
OAuth is only needed to make others use your API on other services, i.e. authorize services to use your API without users of the intermediary service explicitly having to log in into your service by giving user's login credentials to a third party.
What I think you need is OpenID, the cross-application authentication mechanism. You just need to implement an OpenID client, accepting third-party OpenIDs to authenticate users, to subsequently identify them, when they use your service's API. This would have to be supplemented with a normal 'local' user authentication mechanism (i.e. login/password entry page)
You will need OAuth to provide an ability to use your API on other sites, though.
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.
Most Oauth implementations require the user to login with the originating site in the process.
An example is: http://code.google.com/apis/accounts/images/OAuthDiagram.png
What if I want to use my own account to access a generic feature, such as a search for people outside of my network, and don't want them to login? Is there any way to login with my own generic account?
I am creating a web service that interacts with many social networks by searching them, so by forcing the user to login several times to each network if I want to use their API is just bad user experience.
You could try to authenticate your account manually and then store the access token. Any subsequent request would be made with the stored access token.
There are several problems with this approach:
if the token expires, you have to reauthenticate
you might run into request quotas if you do all requests from one account (e.g. Twitter)
If possible, I would use something like HTTP basic auth to authenticate to the services.
When you are strictly speaking of OAuth, it is not meant for this scenario. Try looking into SSO (Single Sign-On).
OAuth can also be implemented in conjunction with SSO solutions.