I'm developing an app that uses the oAuth authentication for Google accounts. The problem is that depending of the login-hint that I'm sending to the page (#gmail.com or #googleappsdomains.com) the page has an appearance or another.
My question is... Is there any way to load always the same oAuth page and not a different one depending of domain (login-hint will always be send as a param, is not a solution to not send this param).
I think login-hint is working as intended. If the browser is logged into multiple Google accounts (and a lot of them are), if there’s no login-hint, then the person is going to see the Google AccountChooser, asking them which account they want to use. If login-hint is there and they’re logged into that account, things just go straight ahead. There are other sources of variation... depending whether or not they’ve previously approved your scopes in the login-hint account, they might or might not get an approval screen, and depending whether or not they’re actually logged into that account, they might or might not get a sign-in flow.
So your objective (always having the same flow) is probably quite hard to achieve. I’d ask myself if it’s worthwhile, because these flows are quite carefully designed and work pretty well.
Related
I know that OAuth 2.0 Authorization Code with PKCE Flow is the best practice of OAuth. We plan to use it for our WEB application.
But I don't understand how can I use this flow for native UX my mobile app without using a browser for authentication (https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472)
Using a browser is unacceptable in our case.
The mobile app has a Login Page where user enters their сredentials, 3-th-party authorization is not.
Is it possible to use Authorization Code with PKCE Flow or should I use the OAuth2 Resource Owner Password Grant in my case?
Are there any other alternatives?
There are two main options here:
1. AUTHORIZATION CODE FLOW + PKCE
This is typically done by plugging in AppAuth libraries and using a Chrome Custom Tab or ASWebAuthenticationSession window so that the user experience feels integrated. These are the main advantages:
Login tends to be more user friendly, and features such as password autofill and single sign on across multiple apps works best
You can potentially support many authentication options rather than just user name and password
It will do better in third party security reviews (if applicable) since it is the standard option - eg Google use it for mobile Gmail
There is a learning curve in implementing it though. Also, it has a prerequisite of using an Authorization Server and externalising the login user experience. This can be difficult to manage politically at some companies.
2. RESOURCE OWNER PASSWORD GRANT
This is also possible as a short term solution but is deprecated in OAuth 2.1 and will fare less well in security reviews. It limits you to password based sign in and can sometimes result in long lived access tokens (if refresh tokens are not supported). Plus points are that you are more in control of branding and login screen behaviour.
PRACTICAL NEXT STEPS
If you want to look at some working apps that use Code Flow + PKCE, feel free to run the apps from my Quick Start Page. Maybe then you can make an informed decision based on factors such as User Experience and what is most important to your stakeholders.
If you are just looking for first-party signup and login, Ory Kratos is an open-source solution that does not use OAuth2.0 for first-party flows.
So you can skip the complexity of OAuth2.0 entirely!
A nice bonus is that you don't need to open a browser window (as you always have to do with OAuth2.0, there is no way around it).
Check out this tutorial for some concrete implementation details:
https://www.ory.sh/login-react-native-authentication-example-api/
We have a client that we have built a webapp for and we allow their members to access this webapp via sso through an ADFS server they have provided. After implementation of the webapp the client came back to us and said that we need to query a database table in order to determine if the user that logs in via sso should be allowed to access the webapp or not. We also need to now access this table to determine what type of account this user is - i.e. are they a staff administrator, paying member or a free member
I have done several SAML/ADFS integrations but never configured ADFS myself. I am finding it hard to figure out exactly what is best practice here. I would have thought that the best practice would have been for their ADFS server to have complete control over access to the webapp and restrict based on some sort of grouping of their users. I would also expect that key attributes about the user such as TYPE come back in the response upon successful login. I am worried if we implement things the way they want we are not going to end up with a robust solution at all.
I am really looking for some advice on what is best practice and some information so I can reply with a punch because I feel their IT team who is demanding we do things in a particular way are largely attempting to avoid implementing something that they are responsible for.
Thanks for your time and advice!
ADFS is claims based and the best practice is to restrict access based on an AD security group (in ADFS terms a role) which is passed in the token as a claim.
We are developing an app which our customer would like to install for some of their teams. However, we have not yet listed this app on the App Marketplace and would like to install this application for our client's sub-org without needing to do so. Is there any way to have the admin grant access to our app for only this sub-org?
We checked out domain wide delegation, but it seems to be for the whole domain. The only other method seems to be using OAuth, but this would involve every person individually signing up, and not a one time action by the admin.
Thanks!
As far as I know.... no.
But you definitely could simulate that. For instance make your app completely public, but on the login page check for the IP of the logged customer and then decide if it comes from the right subdomain. If not, send the customer to a "403" page.
Or you might be able to create ONE user, using the same email for the whole organization?
Currently I'm developing a GAE application in golang that would allow the users to log into the service using OpenID from Google. Each account would be mapped to one Google account obviously. Should I implement captcha for user registration, or does using the OpenID already prevent the service from a bot attack?
Are you accepting any OpenID? Then this is not sufficient protection. Anyone can put up an OpenID site on their own domain, use a script to create a billion accounts, and log in with one of them on your site.
Are you accepting only specific OpenID providers? Then you're not using OpenID as it was meant to be used (and, in fact, expressly the opposite of why it was created). But the answer then would be: do you trust that the OpenID providers have done their own due diligence at the time of account creation to prevent spam accounts?
Regardless, you'll likely find that captcha's a poor solution, and currently all implementations of it are broken (but that's a whole different topic).
First of all, fear of a bot attack is really a preliminary caution. Parsing CSRF tokens (which you should use anyway) and dealing with cookies would already cause enough pain to an attacker. I doubt anyone would trouble himself into setting up very own OpenID provider which is the only way one can do that.
Secondly, App Engine's OpenID Federated Login is the User API feature, not Go runtime's one — you can use any OP with it (Facebook, Yahoo!, Steam... Google). User API provides two modes (configurable via Application Settings): OpenID Federated Login and Google Accounts sign in. Which to pick depends on requirements. If all you need is user's Google account you'd better use the latter, when if it's simple password-less sign in with nearly everything, choose OpenID. From the app's perspective both look identical. Best way to go is OAuth, though.
Getting back on the question, both Google Accounts API and OAuth would make such attacks almost impossible and with OpenID it is a little simpler.
https://developers.google.com/appengine/docs/go/users/overview
Is there a way to use Google accounts to authenticate my own personal website? I understand Google provides an API for authentication but it requires redirection. Is there anyway to have a customized login process without being redirected to Google?
By the way I'm a total noob when it comes to user authentication. I did try to find a preexisting thread but was unable to find one.
For exactly the reason given by Kris, Google (along with similar OAuth providers) doesn't allow you to authenticate users directly.
It's a security measure to protect both themselves and their users from the Web equivalent of ATM card skimmers.
I have a usability answer rather than a technical one.
I am unsure if this is doable but, even if it is doable, I would highly suggest NOT doing it. Think of it this way: you want a user to use their Google account to login to your website. If you were that user, would you feel more comfortable entering your login information on a Google website or someone else's website that has nothing to do with Google?