Is there a way of passing username/ password to Google Apps IDP and get a response as to whether a username/ password pair is correct?
I know I can use OAuth for authorization and access user data but note that I want to check if his credentials itself are valid. OAuth for sure will not work for me. I need a way to directly query Google Apps' IDP particularly not to use it and access something else.
I wish to use this to customize the Google's standard login page itself. OAuth doesn't allow me to do that.
Short answer: no.
Google actively tries to prevent the scenario that you describe because it would mean that Google users hand over their Google credentials to your application, aka. phishing.
That precludes branding of the Google login pages as well since it would make it harder for users to verify that they actually type in their credentials on a login page provided by Google.
As said in the other answer, Google Signin with OpenID Connect (built on top of OAuth 2.0) is the standardized way to offer users login to your application with their Google account.
Google (Apps) accounts can be used as an OpenID identity provider. By implementing your app as as a relying party, you could authenticate your users based on their Google accounts. Much like stackoverlow Google login: http://code.google.com/googleapps/domain/sso/openid_reference_implementation.html
With SAML SSO, Google acts as a relying party. While its possible to use provisioning API and clientLogin, this is not supported and is possibly against Google Apps ToS.
Related
I'm a bit confused about Identity Providers in a project I'm doing with Xamarin Forms.
I configured Facebook as an IP with Azure Mobile Apps following this page
https://learn.microsoft.com/en-us/azure/app-service-mobile/app-service-mobile-how-to-configure-facebook-authentication
It works, but my doubt is, how can I use the MobileServiceUser result of the authentication process to, for example, post to Facebook or get personal information from Facebook. Is this possible?
Thanks!
This is how I think about it.
Identity providers are used to provide a third party guarantee of WHO a user is.
The Mobile SDK lets you do Authorization. So you can decide WHAT the user can do on YOUR service after you know WHO they are.
Any thing you are doing via facebook would still need to be done through the Facebook API/SDK using the token their Authentication process returned to you.
Finally I found the solution to my problem.
What I was trying to do is get information from Facebook after I have authenticated myself.
All I had to do was invoke
await client.InvokeApiAsync("/.auth/me");
After authentication and thats all, the response of that request has the token to access the Facebook API. These tokens are saved in Azure.
For more information:
https://cgillum.tech/2016/03/07/app-service-token-store/
Thanks!
I have a REST service that my mobile app uses to authenticate when the users click on the Facebook or Google icons.
The service accepts the user's id from the provider and checks if it exists on the database and then issues the access_token to be used for the other methods.
The problem is that I just thought that it could be pretty easy for someone to intercept the calls and discover which service authenticates and what the user id is and then call it with to get a token.
How can I avoid this?
I think you just need to separate the authentication and authorization functions. You can let Google (Google Sign-In) handle authentication. If you follow the API they will securely authenticate the user and send you the token which you can validate.
Once you know who they are for sure, your site can safely authorize that user approriately. For example, they might be an existing user, need to make an account, be an administrator. You can make those authorizations on your site based on the user authenticated by Google (in my example).
Twitter, Facebook and others do the same. Also see OpenID Connect.
Recently I've been doing some research into OAuth and OpenID/OpenId Connect and it's all just left me confused as to what is best to use and what is safe.
Originally I thought you could just use OAuth2.0 to log a user in (using their ID as a way of remembering the user) but then I found out that due to how the spec of OAuth 2 works, hijacking tokens would allow a malicious user to impersonate another person. Which is why it's stated that you shouldn't use OAuth 2 as authorization.
But then I have been reading that providers as such as google and facebook have decided to go away a little from the standard and ensure that such attacks are not possible. So my question, what OAuth providers are safe to use to gather a users ID to be used to log them into my service.
Also, facebook is offering another service called facebook login. From what I can tell it's OAuth but without the impersonation issue (obviously) AND the app creator cannot do other OAuth features as such as posting on behalf of the user without getting their app reviewed by facebook. Why would I use facebook login over OAuth which gives me all those permissions without review?
Thanks a heap everone
I have a web application that's going to be available for all users on my google domain.
Is there a way of allowing the application to manage user's emails, calendar, etc without requiring the user authorization using the fact that all users are part of the domain?
You will need to have a look into Google Apps 2-Legged OAuth APIs, they will allow you to access/manipulate users data without their authorization.
You can find the list of available 2-Legged OAuth APIs here.
Unfortunately you will see that you cannot do as much with the 2-Legged API as you can with the 3-Legged API. However, 3-Legged OAuth requires the users consent at least once.
Is OAuth sensible to use when the user account info (user id's, passwords, roles, etc) is going to be maintained in our own back-end and when there will not be any sharing of resources with other sites? Or is sharing the whole point of using OAuth?
Background:
I'm working on developing an enterprise SaaS product and we are creating a RESTful API to be used by our front-end applications. Consumers of the API will be browser and native smartphone (iOS & Android) applications that we develop. Since we'll be supporting multiple client types, it makes sense to create a RESTful API that all our client apps can consume.
Naturally we need to secure this RESTful API. We are considering authenticating using HTTPS / Basic Auth but we are aware of some of the well known drawbacks to this approach.
Some quick research shows OAuth is highly recommended. But most of what I find with OAuth is in the context of authorizing web sites to share information on behalf of the user.
Any info if most welcome.
Good question, and we're having a good discussion on this over at API Craft:
https://groups.google.com/group/api-craft/browse_thread/thread/b87fd667cccb9c00
Here's the answer that I posted there:
I think this is a good use case for OAuth, actually.
First of all, with OAuth your mobile app can store an OAuth token on the client rather than the user's "real" password. So, you can have the app automatically "log the user in" by getting an OAuth token without having to store the actual password on the device. If the user loses the device or if it's compromised somehow they (or you) can wipe the OAuth token without requiring that the user change the password and blow away other things that they might be doing with your API. There are similar examples for an Ajax-style web app but it depends more on the specific way that you build the client.
Second, the OAuth token is associated with a unique key that identifies the app that is making the API call, and that in turn identifies which developer built the app. That gives you options like tracking usage by application, turning off an application that might have been compromised without disabling the whole API, and if you ever want to open access to third parties or partners who build apps for your API, you can offer different levels of service to other customers.
Third, your IT security people will be happy if you tell them that you never store a password on the user's mobile device or stash it somewhere in their browser.
Fourth, you have the option of browser-based login for the mobile app. That means that the mobile app will never see the user's password, and also that if you want to implement two-factor security or something like that, you can do it in the login screen without changing the mobile apps. Now, the downside is that the user sees a browser window pop up. That's why OAuth gives you a few different ways to get an access token for an app, so you can choose whether you need to have browser-based login or have the user enter their password directly in the app.
Fifth, how do you know that your API will only ever be used by your own apps? If you use OAuth now then you will have an easier time making that transition later.
Yes, this is a very good fit for OAuth. You can still use HTTP Basic over SSL during the handshake for authentication. The output of the OAuth handshake will be a token which can then be used to consume the API. This way, the application does not need to store the credentials and tokens can easily be revokes with minimal user impact.
OAuth 2.0 defines a number of different grant types for accommodating different situations. It sounds to me like the 'implicit' or the 'resource owner password credentials' are the most appropriate but you may want to consider each carefully.
You should not implement this directly in your API but use infrastructure to delegate the OAuth support and token management on behalf of your SaaS API instead.
Take a look at
http://www.layer7tech.com/blogs/index.php/oauth-token-management-2/
and
http://www.layer7tech.com/products/oauth-toolkit
Hope this help,
-fl
I implemented an OAuth for Django nonrel with piston to expose my APIs to consumer. There are a number of kind in OAuth(2-legs 3legs).
Generally, supporting OAuth is quite a bit challenge. You have to obtain the request token, authorize it, store the access token to sign every request you want to authenticate.
Advantages
- You don't have to send username and password everytime, secure.
- Enable third party to consume your app.
Disadvantages
- Make 2,3 round trips to authenticate.
- Complicated to implement it by yourself.
I'm pretty sure that you can find a number of library that allow you to:
- Expose your Api and support OAuth. E.g Django piston.
- Sign your requests by adding headers to them. E.g Oauth-signpost.
OAuth is only a token and the requesting App will issue one. You can read more in pingidentity.com where there are several webinars on this topic(cloud identity and user provisioning) as well.