I have a first-party authorization server and I'm developing a first-party native mobile app and a SPA as a client. I noticed that the latest version of OAuth 2.0 no longer supports the "password grand type" and recommends using the "authorization_code grand type" instead, for mobile apps and SPAs.
My app has a native login screen and my SPA has its own unique login screen, and I want to avoid redirecting the user to the authorization server's login page or prompting a popup for login credentials since the authorization server is a trusted first-party server.
I'm wondering if OAuth 2.0 is still a good choice for first-party mobile app clients or SPA in this situation, and if there is a way to directly request a token through an HTTP request flow using user credentials obtained from the native mobile app login screen?
Any advice or insights on how to proceed would be much appreciated. Thanks in advance!
I found these two articles on this topic.
https://www.ory.sh/oauth2-openid-connect-do-you-need-use-cases-examples/
https://www.ory.sh/docs/hydra/concepts/before-oauth2
Related
I am confused about the different login methods and the impacts on the user experience.
I would like to do native mobile app login on iOS, that means the user is not redirected toward the web page (or in app browser tab) to login. For example : All banking applications (Ex: N26) the login method is always the same : User enter his login / pwd and then he connects.
However, when I see the "Best practice login app for mobile" I can see they use authenticate + authorization code flow with PKCE. But using this method, my mobile app has to be redirected to the authorization server (Like when we want to connect with google).
So my questions are :
Is is possible to do native login using authorization code flow with PKCE without opening an in app browser tab ?
In terms of security, authorization code flow is better than native ? If yes, why all banking mobile applications are not using it ?
if the authorization server is the same than the resources server, is it possible to not have this redirection for the login ?
For now, my server use OpenID, tomorrow maybe OpenIDConnect.
Thank you for your answer :D.
Context
N26 as well as most banking apps do not support Single-Sign-On (SSO).
Auth code flow + PKCE is a way of securely having your user login with SSO, usually using a well known Identity Provider (IdP) as Google. Then, assuming your selected IdP follows the OIDC specs, you will be able to receive an idToken which will represent the user who just logged in and some of her details (called token claims) like her email, name, etc.
Answers
Auth code flow + PKCE is related only when you use OIDC SSO, not with native login.
In order to implement a native login you would have to be the "authority" who keeps the data required to authenticate users like email, password etc. Otherwise, Google (or any other IdP) is responsible for that. SSO provides better UX (as long as the redirect to the IdP is not poorly designed) and users prefer it since they are usually already logged in to their IdP, thus they do not have to remember and type credentials. However, the reason that lots of banks do not use SSO is that they do not trust Google. If Google gets compromised, the malicious party would be able to issue tokens that would allow them to impersonate anyone. Same for availability. If Google goes offline for some reason, users will not be able to login. I guess banks believe that they can provide better security and availability guarantees on their own.
Again, you need the redirection only when using SSO OIDC. If you are not using that, and end up using a native login no redirection will be needed. That being said, it is a good practice too keep your authentication server separate to your back end.
I have been working on implementing OAuth in my project's API. As a part of this project, we have a mobile app that authenticates a user via this API, using a password grant (this grant actually sends the given credentials on to an upstream authentication server that doesn't implement OAuth - so it is required).
This mobile app also has the functionality whereby it opens a webview to some pre-determined websites. The idea is that these websites would be able to authorize on behalf of the user using the authorization_code grant.
This is where my question comes in. When authorizing the websites, we obviously require that the user be authenticated with our API. However, the user authenticated via the password grant in the app, and not in the webview.
How would we transfer the authentication from the app to the API when the authentication was done in the app? My thinking is that setting a cookie containing the token on the API's domain would be the best way of implementing this?
Apologies if the question is not as clear as it could be. I'm struggling with how best to phrase and explain my question.
Good question - I have implemented this in the past via a strategy pattern:
When webview is hosted in a browser (which was an SPA in my case), handle tokens in a standard SPA manner - eg token renewal on an iframe / full screen login redirects
When webview is hosted in a mobile app, detect this via the user agent and call back the mobile app to do things like refresh a token or initiate a new mobile login
It is tricky but makes sense since web / mobile have very different solutions for token renewal / storage / login
It is the sort of practical real world use case where you find pretty much zero guidance online. Happy to answer any follow up questions.
We're working on a new API that we wish to secure with api tokens. These tokens are tied to a user and an application. These 3rd party applications use OAuth to authenticate themselves (using and app_id and app_secret). This works great.
However, we have our own mobile app which will also consume this API. Obviously I'd like to avoid having the user get asked the familiar "would you like to allow this app to use your account" when performing a login. Obviously we can't embed a secret in the app, (hence pure OAuth would be unsuitable for this). However, I don't want to create an API endpoint to which a username and password can be sent since this would effectively bypass the OAuth scheme entirely.
On the web site, we can just dump the api token into the DOM after a regular form submission, and allow the Angular app to use it from there; but this simply isn't practical in a mobile app.
So my question is; how can we securely identify login requests from our own mobile application? How does (for example) Facebook know that it's the Facebook app supplying the username and password when authenticating, and not some 3rd party application?
I'm creating an app for iOS that consumes an API I've created, which requires authentication and authorization of users. I'm thinking of using OAuth to let the mobile users do this with Facebook. This is an internal API that isn't meant to be exposed to third parties.
Anyway, I'm a little confused about the abilities and limitations of OAuth consumers versus OAuth providers. Basically, I want to implement "Login with Facebook" functionality from the iOS app. It seems to me that this implies that my API should be an OAuth consumer, but the problem with this is that the login flow for a web app assumes a browser -- an NSURLConnection instance isn't going to know what to do with an HTML login page, and even if the redirect to the login page was made to work by prefixing the redirect URI with the fb:// schema, surely the login form is going to pass the authorization token back to the iOS app and not my API?
So my question is: is there a way to implement my API as an OAuth consumer? If not, and I should implement it as an OAuth provider, what does logging in with credentials from another provider like Facebook even mean?
I think things are a bit mixed up:
OAuth is to Authenticate your app against facebook. A user grants
access to his FB account to your app on behalf of him
"Login with FB" is the other way round and is not OAuth: A User
with an FB account is using this data to register AND login to your
app.
The entire flow of the # 2 can be read here.
Is there a way to authenticate to Facebook / Twitter using basic authentication? the application I am working on requires posting to those two sites without the need to open the oAuth Dialog.
Both twitter & facebook don't support basic auth.
No, thank goodness.
Basic authentication requires that you take the user's password, which is a secret between them and Twitter/Facebook. You shouldn't be asking for it.
If your app is physically unable to display the dialog, OAuth 2.0 (not available on Twitter) offers a way (last I checked) for an independent web browser on another computer to perform the OAuth authorization process to your app running on some limited device.