I need to login to Auth0 without login prompt on my intranet under certain circumstances.
I have a very particular use-case, where I have created a very special user in auth0 called "analytics" which has access to some of our analytics in Tableau.
I created it, so I know the login password and can create refresh tokens with unlimited life.
I had to create this user in auth0 and have it managed by auth0 because that's how our company access Tableau and I can't change this policy.
In another web application, which doesn't use Auth0 at all and has its own authentication methods, I need some users to have access to the ressources that the "analytics" user can access. (there also, no way to change this web application to use Auth0, because that's another company policy and I can't change it)
To achieve this, I have no choice but to allow all logged in users of the web application to be also automatically logged in as "analytics" in auth0.
Since this is an intranet, it is perfectly ok to hardcode a refresh token or login password. Also there's nothing too confidential about the analytics in question.
I know how to use the refresh token to call an API, but I don't know how to use it to "login" the user, e.g. his browser has the right cookie so auth0 knows that his browser is indeed him.
Is there any way to achieve this ?
I don't understand very well the OAuth 2.0 protocol, hence my question.
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.
As background, I'm using the Google OAuth2 NodeJS client, but I think my question is more abstract / technology independent.
My website is single-page application that communicates via AJAX to the server.
When a user first visits my website, I perform an OAuth2 flow which redirects them to Google to log in, and then redirects back to my site with an access token. I store this access token in a cookie, and use it to handle various calls made to the server via AJAX.
My challenge is that I'm unsure what to do when that access_token expires. Should I be storing the refresh_token in a cookie as well, and using that, or are there security issues in doing so?
Should I be redirecting the browser to perform the login flow again? That seems fairly ugly for a single-page application.
You can do the OAuth2 flow via js in the background(like the login flow with the popup window), and if the access hasn't been revoked for you app id, then the user shouldn't see anything about it. Although you can set a hint on the user email to authenticate, this may not work.
The other way that you mentioned, is the refresh token, that you can use to ask for a new access token, without user interaction. Maybe that would be the better idea, but remember, that you will only get a refresh token if you set the access type to offline.
I am in the process of designing an app that is supposed to let you login using either a username/password combination or facebook login. We have a custom OAuth server that uses user credentials to authenticate users. Now, the question is how to add facebook into this.
As I see it now, when the user wants to login with facebook, the client does all the work and gets the access token in the end. But how do we let our server know that this access token is a good one (and corresponds to a user in the database)? To me it seems like our OAuth server should be able to handle this as well, and I'm just missing the how.
OAuth supports different scenarios (flows). Client-does-all-the-work is so called "implicit" flow.
In your case it would be better to use authorization-code flow and extend your OAuth server. You put a "Facebook" button on your login page and instruct Facebook to redirect to a new special page on your OAuth server. Delivered authorization code then can be exchanged to the access token inside of your OAuth server and the server may issue its own session and tokens based on this.
Goal:
Allow a user to authentication with Facebook into an iOS application which requires access to a protected web service that I'm running.
Assumptions:
There is a native authentication (and registration) system in place for those users that opt not to use Facebook for sign in.
Details:
Assume we want to offer the option for a user to sign in with Facebook without creating a separate account/credential for our system.
Because we support our own native auth mechanism (username and password) we have our own user IDs and issue an authentication token that is used for subsequent interactions after the initial credential validation.
I'm surprised that Facebook doesn't have best practices for this in their developer documentation. All the existing documentation is either assuming you are building FB auth into a website, or a standalone mobile app with no service that requires authentication.
Here's my initial thoughts on how this would be designed but want validation on whether it's correct.
Client pops the Facebook iOS Login
UI User signs in with Facebook credentials and gets access token
iOS App passes access token to our server
Our server talks to FB graph API using access token to (a) validate the token and (b) get the FB user ID for that access token.
e.g. Our server would call https://graph.facebook.com/me/?access_token=XYZ which would return profile info in a JSON object
Assuming it's valid, our server extracts the User ID from the JSON object and checks whether the user already has an account. If so, we issue our own auth ticket to client to use for that session. If user doesn't have an account, we create a new one with the Facebook User ID, assign our own unique UserID and issue our auth ticket.
Client then passes auth ticket back on subsequent interactions that need authentication.
This seems like the right approach to me but not sure if I'm missing something insanely basic and going down the wrong (complicated) path.
I just dealt with this myself, and here's the part that bit me:
In your step 5... It's possible for a user to register for an account with you entirely separate from their Facebook ID, right? Then some other time they log in with Facebook.... And you just created them a second account and lost their first one.
There needs to be a way to be logged in to your web service, then log in to facebook, and capture the association between the facebook ID and the local account.
Apart from that, your plan sounds solid.
Update: Facebook has added a doc outlining such a scenario HERE
Use https to transmit the auth token to your server, as stated by Facebook
Sharing of Access Tokens
Our Data Policies explicitly prohibit any sharing of an Access Token
for your app with any other app. However, we do allow developers to
share Tokens between a native implementation and a server
implementation of the same App (ie. using the same App ID) as long as
the transfer takes place using HTTPS.
One problem I can see with this strategy, is that somebody can give you an access token obtained for a different facebook app. As far as I know, there's no way to verify that the access token is for your application, so you'll just go on and use it.
It doesn't sound very harmful, though. Generally people/apps try to protect the access tokens, rather than sharing them.
One possible exploit of this would be, for somebody to create their own site or mobile app, obtain access tokens for their users and try to authenticate them, using your API. If this succeeds (the user is has a facebook account in your site), the malicious site will be able to use your API impersonating the user.
It's a bit of a long shot, but I think it could work.
Edit: It looks like there is a way to validate the access token after all. See the answer by #Daaniel on question Get application id from user access token (or verify the source application for a token).
your solution totally works.
Maybe an alternative: why not just get the email on the client from the initial social service request and send to your web service? The web service could just store the email, and maybe a social_provider as well. I understand that your web service will not be able to validate where the email came from, but isn't there a high-trust relationship between your web service and your client? If there is, seems like you can depend on the email coming from the right place. Someone please let me know what obvious thing I'm missing that makes the email-based approach silly...
I'm trying to use OAuth with .NET (DotNetOpenAuth) to send updates to a Twitter account via a web application. I understand the basic workflow of OAuth and Twitter.
Where I'm confused if is it useful in a server web application? I don't want any user interaction.
But how it seems after an application start, the request token needs to be recreated and also an access token. This involves user interaction.
What is the correct workflow for my case?
Storing the request token or access token in config file?
Or the easist way, using HTTP basic authentication?
Thanks
If I understand you correctly your application will not be interacting with Twitter on behalf of your users but will be acting as the Twitter account for your application.
In this case there are 2 main factors to consider.
1) Do you want "from API" attached to each status as will be if you use basic auth or your applications name will happen if you use OAuth.
2) Do you want to put in the extra effort to implement OAuth.
If you decide to go with OAuth you would store your apps consumer key/secret and the accounts access token in configuration just like you would store the accounts screenname/password.
Your "request token needs to be recreated" phrase suggests you might be running into the problem where every time your user visits you need to re-authorize to Twitter, and perhaps you're looking for a way to access the user's Twitter account while he's not at your web site, and how can you do this when their token isn't fresh from being re-authorized. Is that right?
If so, the user isn't supposed to have to re-authorize Twitter every time they visit your site. The token is supposed to last a long time, which would also allow your site to access their Twitter account when they are not directly interacting with your web site. The problem may be that you haven't implemented the IConsumerTokenManager interface, but are instead using the default InMemoryTokenManager, which is for sample use only, since this memory-only token manager loses tokens every time the web app is restarted. Your own implementation of this simple interface should store and read the tokens out of some persistent storage such as a database.