We are using idsrv3 at work and here are my setup and the problematic scenario:
we use idserv with reference tokens, implicit flow, 1 web api and 1 angularjs client.
Our client doesn't want a user logged multiple times on the website.
the user A connects to site on chrome
the user A connects to site on firefox and the token of A on chrome is revoked.
api returns 401 to user A on chrome, revoked worked
chrome redirects user to signin page with oidc-client (signinredirect)
user is automatically logged in, because the authentication cookies are still valid.
We also have a silent renew for the access token.
Now I want to force the kicked out user to re-authenticate but it's impossible to do without deleting the authentication cookies.
How can I achieve that?
I have considered to have a very long access token (stored in session store) and ephemere authentication cookies, or
to delete the cookies just before the signin redirect which will jinx the silent renew.
what is my best option?
thank you.
Related
Has anyone of you seen any example or documents how to do AD Authentication in React.js Application that does not use any Login buttons when User is all ready Authenticated?
I have look many Authentication samples like Microsoft's https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-react has but everyone of them has a Sign-in and Sing-out Buttons not automatic Authentication and redirect if User has all ready logged in and Authenticated. I mean something like SSO style AD Authentication that is usually wanted to Customer's Web Applications. I use MSAL packages.
Any help valued.
Thanks
You can use the localStorage or cookies to store the localStorage or cookies to store the token, and when you reload the application then you can check if the token is valid and available in localStorage or Cookies, if it is then redirect the user to the home page otherwise redirect the user to the login page.
In the MSAL browser, acquireTokenSilent get's refresh token on every call to the token end point. The very first refresh token has a duration of 1 hour. Subsequent refresh tokens all have reduced (the remaining) expiry time.
I have a website protected by azure ad and uses msal, i want to access it in iframe, but it looks it does not work. Is there a way to make it work ? Is it related to the redirect url or other issue ?
You cannot authenticate the user inside iframe meaning you cannot use redirect APIs for user interaction with the identity provider.
You can start with creating your own customer page and allow the user to enter the credentials and then authenticate the user. When the user enters their credentials and clicks on login, the server will return OK (if email/password is correct). After that you should save the token in localstorage and then set isAuthenticated = true.
If you are using the Auth code flow, then you should do the authentication in the outer real page not inside the iframe. Then you will have to login once your authenticated. The concept is that you must fully redirect to the Auth pages in azure ad not in iframe.
You can achieve single sign-on between iframed and parent apps with
the same-origin and with cross-origin if you pass an account hint from
the parent app to the iframed app.
Learn more here
You need to specify in the auth config to allow redirects in IFrame
https://azuread.github.io/microsoft-authentication-library-for-js/ref/modules/_azure_msal_browser.html
So, we are developing a public rest api that is protected by our own Identity server through an authorization code flow. Somewhere in the middle of the flow, we also implemented a consent step (with a different web app) to grant the Api access to some data that belongs to a user's account of another web app of our own. Currently, the consent page is protected by OpenIdConnect, which login page is implemented in the Identity server itself. However, we want expose as little as possible of the Identity server to the public.
With that in mind, is it possible to implement a login page outside of the Identity server that can still authenticate the user in identity and grant the consent? If so, how?
I will start with just explaining the flow.
When an app redirects a user to Identityserver, they come to authorize endpoint to validate the request.
When request is not valid, that triggers an error.
When request is valid and user is authenticated (has auth cookie) they just go back to the client app with the code.
When request is valid and the user is not authenticated, the next redirect would be to login page. It is the place to check the credentials, set the cookie (for the Identityserver app) and redirect back to the authorize endpoint to go further with consent or final redirect to the client app.
Is the answer crystal clear already? Login page is almost the only vitally needed for Identityserver to make possible setting the auth cookie for any further SSO.
Nevertheless you can delegate the login handling to an external app (one more Identityserver instance?). In that case your front login app will perform the steps (1-2-3-4), set the first level cookie, redirect back to the client Identityserver app, which will set the second level cookie on external auth callback action and finally redirect to the original caller. Is this the scenario for you? Possibly so. The original explanation is a bit uncertain.
I have set up an AAD SSO enabled website A that gets an access token once the user logs in. Now, the user has the option to navigate to website B, but on a new browser that doesn't have access to the session of the browser that website A was opened.
Is there a way for website B (.NET MVC Azure hosted Web App) to be setup to accept the access token (for example: through headers) to authenticate the user and establish a newly AAD SSO logged in user on the new browser? (Users can't re-enter their credentials)
In my opinion, access tokens enable clients to securely call protected APIs, so it should be stored in backend. More often we use refresh token and access token at the same time to prevent the access token expiring.
On the other hand, if I have entered the credentials in one browser, then the identity platform knew the request came from me because some information would stored in my cookie of the website, but if I used another browser to visit IDP, it was impossible to let IDP know the request came from me, because I can't share cookie infomation with different browsers.
I find 2 videos on introducing SSO, I think they will help, here is the link.
Hope it will do some help.
To GAE+html5 gurus out there :)
When user logs on to a GAE hosted application, his credentials are stored locally in a cookie (correct?).
After this cookie expires (e.g. if users hits logout on another browser tab), no login_required protected methods will work.
Regular webapp will require re-authentication next time the user navigates to a login_protected url by automatically redirecting to a login screen.
What would be the right way for a cached webapp to be handling this?
My test is a simple login_protected page accessed by Chrome and iOS browser. It's cached and accessible offline as expected. Then, (while online) and after the authentication expires, the server log shows a 302 response which is followed by 200 response of the authentication dialog page, but of course no authentication happens.
Thanks!
If you are using google authentication to provide access to your page . Which means even if you are logged in one of the other google services. Your cookie still exists in the browser. login_required will assume that you are logged on based on the cookie. What you are seeing is a redirection to google's page that's 302. If you want you can manage sessions on your own and check for authentication based on your data in data Store.There are lot of solutions availble for both Python and Java .