I have set up Django OAuth Toolkit in my project where the authorization server is separate from the application server (i.e accounts.example.com and app.example.com). App server redirects to accounts server using authorize flow; the user inputs credentials to sign in to auth server, then auth server redirects the user back to application; so that the app can retrieve tokens.
The above flow currently works as expected. If I do not click explicitly Log out the user and the application signs out (e.g session expires or browser cookies are cleared), the above flow will be performed again and there won't be a need for credentials because auth server still knows who is signed it.
However, I am having trouble with explicitly logging the user out of the application. If a user explicitly clicks login, firstly, the token must be revoked and secondly, the auth server must sign out. What is the proper way to achieve this? As far as I am concerned, I won't be able to use Ajax to log out the user because the session must be destroyed in auth server.
So, I have been thinking of redirecting the user to accounts.example.com/signout?token=${accessToken}&client_id=${clientID}. However, I am not sure if this is the right approach. Is this how these sign out requests work with OAuth? Does that mean that when I sign out from the system, I need to always provide Access Token and Client ID?
Related
I am using ADFS 4.0 for authenticating into my mobile application using OpenId Connect / OAuth2 flow. Basically when I sign in to my application, my mobile appliaction opens a browser to start the flow. Whenever I sign out from the application, I need to fire the ADFS sign out page to clear the cookies and redirect back to the application.
The problem I have is that when I successfully authenticate through ADFS, I need to perform some user validation in my API for the user which sometimes can fail. If the validation fails, the session cookies stays in the mobile devices browser, so the user is not prompted for credentials anymore, so hes stuck in a loop where he cannot sign in to the application again. I really don't even need the session cookies stored into the mobile devices browser because I am using the access and refresh tokens to handle the flow after the authentication.
I have configurated my application as native application / Web API in ADFS. Is there any way I could disable the cookies to be saved in the mobile devices browser or is there any other approaches for this problem?
Are you using authorization code grant flow?
If yes, you can use prompt parameter in authorization request. As explaining in this document about prompt , with prompt=select_account, user will be forced to choose current signing account or choose to login in another account, or with prompt=login, user has to reauthentication...With those values of prompt, you will not be "stuck in a loop where he cannot sign in to the application again"
I'm trying to use Federation from a User Pool. Note, I am not talking about Federated Identity Pool a different concept.
Is there a SignIn API for federated users or is just a hosted UI
Does the app "have to" open a browser on a Sign In URL that looks like https://XXXXXX.au=th.XXXXX.amazoncognito.com/login?response_type=code&client_id=XXXXXXXXX&redirect_uri=XXXXXXX? Can the end-user can stay inside the app, similar to how Google SignIn API on Android works (it pops up a small Google sign in UI, user clicks on their name, you're immediately back inside the app with a token.
How do I launch a browser on that Sign In URL?
How can my app be called back when the user has finished signing in?
Specifically how does my mobile app receive the token from the browser?
Is there a SignIn API for federated users or is just a hosted UI?
As far as I can tell you have to use the hosted UI when you federate a user pool to social IdPs.
How do I launch a browser on that Sign In URL?
This depends on the language and platform obviously, on Android with Xamarin you can use Xamarin.Auth.Presenters.OAuthLoginPresenter.Login() to launch a native browser Chrome at a URL specified by the OAuth2Authenticator you pass in. That OAuth2Authenticator does more than just craft the URL it gives Chrome, its stateful so when you get an answer back in the form of a code or token, you can then call methods on that object to proceed.
How can my app be called back when the user has finished signing in?
Specifically how can the browser redirecting a URL actually redirect you back inside the app. That's done via something called, Deep Links & App Links, here's that concept explained on Android.
I have two servers.
Server A - this is whole bussines logic and API for mobile application.
Server B - in simply words, this is a webpage.
And now, I need to authenticate user on B but, by the 'user-data' from A.
E.G.
On A server I have user with loggin/password. And I need to use this same login/password on B server. There is some nice solution for that? Or just use tokens?
Presumed that you have an authentication mechanism in your server A.
You have to use your server A as an Identity provider. Request to your B-server should have a session header. If this session is not valid in B-server then you have to ask for credential from the web user and forward this request to your Identity Provider(Server-A). If Server-A can identify the given credential, initiate a session in server-B for this user for a particular time frame. You have to manage this session in the Server-B.
When this user logged out from server-B just destroy the session.
tokens should be fine such as a bearer token on the Authorization header. There are different strategies such as opaque tokens vs JWTs, etc.
I actually did a write up on API authentication tutorial and security holes:
https://www.moesif.com/blog/technical/restful-apis/Authorization-on-RESTful-APIs/
I'm using ember-simple-auth for my Ember app, but I don't have an API endpoint to authenticate users, rather it does a page redirect to the form and signs a user in, then redirects back to my app. (I don't own the authentication)
After authentication, it gets redirected back to me, so I know on the server side when a user has been successfully authenticated. How do I manually authenticate the users' session when they are redirected back to my app?
Currently I did a hack to write two cookies: ember_simple_auth:access_token and ember_simple_auth:authenticator.
I think setting up the session store manually is an ok solution in this scenario as that will trigger the session to be restored after the redirect (which is on startup of the Ember application). I'd maybe configure a custom authenticator that redirects to the external login page in the authenticate method. That way you have that redirect centralized and it will also be triggered automatically whenever Ember Simple Auth automatically enforces session authentication (e.g. from the AuthenticatedRouteMixin).
I want to be able to authenticate users of an angular.js application using oauth, but I do not want to store any tokens on the frontend because I have seen that it can be fairly complicated to do so securely. Is there a way to pass some sort of credentials of a user to my django web application, where is can authenticate the user with some oauth provider and save that information in a session? To make it simple, here is the process I want
User is logged into some oauth provider, i.e. stackexchange
They click a "login with stackexchange" button on the front end angular app
Their login credentials are sent over to the django application through a restful api
The django app which receives these credentials attempts to get a token using rauth
If the server receives a token, the user is logged in and their information is saved in a session, otherwise they are given an error
Is this sort of process supported by OAuth2 providers?
Step 3 is incorrect: that authentication process is handled entirely off-site, on the OAuth provider's infrastructure, e.g. StackExchange.
This kind of flow is certainly possible. I would check out the Facebook example, which uses Flask, but provides a similar framework for how you might go about this in Django.