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.
Related
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.
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.
I built my APIs with laravel 5, both my web application and mobile app use the same APIs. On the web app there is a default expiration of 60 minutes after which user will have to log back in again. However on mobile i do not want that, no automatic session expiration for mobile, the user can only be logged out after they have clicked the logout button on the app.
I use JWT with satellizer for my authentication, i would like to know how to achieve this.
I have the same setup as you have on my web application and mobile app.
I simply store the username/email and password on the phone (native) and everytime the user opens the app it does a call to receive a new JWT.
When the user is loggin out on the phone, the password is removed.
I think this is the simplest solution, and for security you can encrypt the password in the storage.
I believe the current practice based on this answer is that you prolong or refresh the token before it expires. I do not believe you can't not have an expiration.