I have several apps that connect to a central OAuth2 server (this is the only login method). When a user hits Log out, I want him to be logged out of all the apps and the OAuth server.
All the apps are Django at the moment but that might change, so I'm looking for the most cross-framework way to do it. I must also keep in mind that all the apps might handle sessions differently (some server-side, some client-side).
All logouts must be handled by POST requests as the good practice recommends.
The strategy I have in mind:
On the app, the user clicks on Log out
This Log out link points towards the logout page on the OAuth server, on which a POST request to /logout is issued immediately (or after a countdown).
The session is killed on the OAuth server and the user is logged out of it.
A ?next=... parameter redirects the user back to app A.
The app pulls the user status from OAuth server (server- or client-side) : if logged out from the OAuth server, then logout from the app also.
New apps would just have to implement this pulling mecanism along with the logout link pointing towards the OAuth server logout page, so there's nothing to configure in the OAuth server for new apps.
Do I miss something?
you may want to follow this draft, https://openid.net/specs/openid-connect-session-1_0.html
Related
I am writing a Django app that uses a 3rd-Party Authentication Service implemented with FusionAuth.
I can successfully register and login (using the authorization code flow).
However, logging out is not working. I can logout from the local Django app, but when I try to login after that FusionAuth recognizes that my access_token is still valid and just goes directly to the redirect page (the page you usually goto after successfully logging into FusionAuth).
Clearly I don't understand something about FusionAuth. I have tried both the python client and the restful API and I don't really understand what it does. According to the documentation it "...is intended to be used to remove the refresh token and access token cookies if they exist on the client and revoke the refresh token". Why then is the access_token still valid?
There seem like a couple of issues here.
First, you need to redirect the browser to https://your.fusionauth.instance/oauth2/logout and that will delete your FusionAuth SSO session. That will stop the behavior of FusionAuth redirecting you. This is because you have an SSO session cookie, and going to that URL will delete it.
Second, if you want to revoke the access token, that takes a bit more work. It is stateless. It's not the same as a session, and is distinct from the SSO session mentioned above. The access token is something you present to other APIs, not to FusionAuth. Here's some more info: https://fusionauth.io/learn/expert-advice/tokens/revoking-jwts
Hope this helps.
We developed web apps in django framework. We have an enterprise Identity Provider which is PingFederate. The main home page (which is different from our site) from chrome browser and edge browser directly recognizes the user and logs them in all the internal websites. We are also on the same network share same domain. We also want to integrate SSO and want to authenticate our users directly with asking password. I researched every where and got to know the authentication is happening by kerbose authentication. Somehow the edge or chrome is sending some token or id or some TGT ticket to the Identity Provider then they will authenticate and send the username back to the client browser. Can any one please help me how to solve this.
Thanks in advance.
I solved this problem and wrote an article about it. Please feel free to see that article.
https://medium.com/#manishkumar.bobbili3/how-i-integrated-ping-identity-with-django-web-framework-for-single-sign-on-sso-9be21b953bc5
It sounds like you want to integrate with the PingFederate solution to use it as the identity provider and allow the users of your web apps to login through SSO. If that is the case, you would need to work with whoever responsible for PingFedereate if it is another team.
Checklist with the PingFederate Admin
You would need to know if you need to choose the directory will be used to log the users in.
Which user attributes you would need to get back in the SAML response.
Will you sign the SAML request using your app or not.
Will you start the SSO cycle from your app, which I believe you would, and you will be using SP initiated in this case.
Otherwise, it will be the other way around and will be using IDP Initiated.
SP Initiated - User will call the app URL first and then redirected
to Ping URL and be sent back to the app.
IDP Initiated - User will call PingFederate URL and will be sent to the app after authentication.
I will list the steps in here in case it is your team who is also responsible for PingFederate solution:
Changes in PingFederate as SP (service provider) connection
Create a new IDP (Identity Provider) Adapter for the login page if needed.
IDP adapter will be using a Password Credential Validator to do the authentication and also has the configuration for which HTML pages to present to the user.
Create the SP connection in Ping with the stuff in the check list.
The connection here will use the adapter in the step above to present the login page
Then check the user credentials and establish the SSO session if successful.
Assemble the SAML response with all the required attributes.
Sign the response and send it to the application endpoint configured inside the connection.
Changes in the web app as the service provider for the user
The application will need to send the SAML request to the endpoint of the new connection in Ping.
Wait for the response on the dedicated endpoint.
Verify the SAML response signature using the PingFederate server's public key.
Create the local app session and move on.
If you will be using OpenToken, this will change to have another interaction of Adapter-to-Adapter. Just reply with that if this is the case.
I have a web app communicating with a backend through a couple of REST endpoints.
I also have a home page where people can become customers to the above mentioned web app.
All the web app's endpoints requires authentication (a logged in user) to be called (JWT tokens) but on my home page I have a "Become customer" button which makes a POST /customers request, which I have to leave public (But I don't want anyone to be able to spam my endpoint with new customers.
What is the standard way of getting around this problem?
I'm using Python, Flask and Flask-JWT in my backend.
The only option would be a user role that is added, for a limited amount of time (30mins). If the user has this role, then they have permission to view it.
Make sense?
I'm working on a project which has it's backend on python/django and front end in react and redux with client side routing using react-router. Please suggest me some ways of doing user login authentication/validation in react with the django token generated/stored at the backend. The login flow should be something like this:
User table with email and password created in django, auth token generated by django.
User logs in for the first time, api gets called by react, on successful validation server responds with a token which I'll be storing in a session. All the subsequent calls to the api will include this token for authorization.
Secondly, I'm confused about how the secured client side routes will be authorised? On the basis of the user logged in state or what?
PS: I'm only asking suggestions for the best ways to achieve this and nothing else.
With this a year old, you may not need this, but maybe others could use it. I ran into a similar problem and wrote a package so I wouldn't have to keep writing authentication for django...
drf-redux-auth
It's just provides actions, reducers, and basic (example) components for authenticating with Django Rest Framework using token authentication.
I'd be interested to hear how you decided to handle the authorization piece with react-router...
I'm working on a Django application with users through Django's auth, on the other side there is an Oauth2.0 server that already has all users and their permissions registered. My goal now is to integrate the Django app with the Oauth2.0 server so we won't have to administrate the users ourselves. This would make it so the when the users want to log into our app they are redirected to the Oauth2.0 login site and then redirected to the home of our app once they login successfully.
I think I understand how Oauth2.0 works but I have a couple of questions I couldn't find anywhere else.
Is the scenario I'm describing possible? As in the users would no longer have to be registered in our app and a 3rd party Auth server would provide access to our app or not.
Once I get the access token after the user login where is it safe to keep the access token? I was thinking I could save to AT as a session variable so as to keep the end user's session linked to his account which is external to our Django app.
Every time the user makes a request I would check the AT I'm keeping, if the verification is OK our app responds with the view, otherwise the user is redirected to the login. Is this flow correct or am I not understanding how this integration would work?
What would happen in the case the user is given more permissions but I hold an old token? How do I handle these cases?
I would suggest using a third-party application, like django-allauth. You can simply disable creating local accounts, and enable a single custom social provider that interacts with your OAuth2.0 authorization server.
As noted here, the process of creating your own custom OAuth provider isn't documented, but shouldn't be too difficult.
Once I get the access token after the user login where is it safe to keep the access token?
Allauth will store the access token in the database. If you want to put it in the session too, you can, but there's no point unless you want the client to make requests to the resource server directly.
Every time the user makes a request I would check the AT I'm keeping, if the verification is OK our app responds with the view, otherwise the user is redirected to the login. Is this flow correct or am I not understanding how this integration would work?
That's fine. If your authorization server has no way to invalidate issued access tokens, though, you can just assume that the access token is good up until the expiration date.
What would happen in the case the user is given more permissions but I hold an old token? How do I handle these cases?
Just use the access token normally. If the resource server indicates that it's invalid, prompt the user to log in again. You will get a new access token for that user that reflects their current permissions.