Does the msal library prevent token replay attacks?
How does it stop someone from taking the access token from the redirect URL and using it in another application?
I'm not sure if Azure AD handles the protection or Microsoft Authentication Library (MSAL) Microsoft
How does it stop someone from taking the access token from the redirect URL and using it in another application?
MSAL can't really do anything about something accessing the URL.
That's the browser's duty.
Same-origin policy requires that only script on a page with the same origin can access the URL of an iframe.
So even if I put an iframe on my website that did hidden login for one of your apps, I wouldn't be able to get the token if the redirect URL is on a different hostname from mine.
So let's say your app has one reply URL configured: https://yoursite.com/aad-callback.
If I wanted to take the token, my site would need to be hosted on yoursite.com.
There is no way for me to ask AAD to return the token to another URL.
Another choice would be to intercept it in flight to your app.
But that would require man-in-the-middling the TLS connection.
If someone can do that, you have bigger problems.
Replay attacks are prevented by using nonces, a new value is set in each authentication request: https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/3fb9ce5a16ea462336eee62b496dfae8611f0fbc/lib/msal-core/src/AuthenticationRequestParameters.ts#L39
Related
I have a client who is using OAuth2 for single sign on with their own login page. Once user is logged in they will be redirected back to my React SPA i'm building.
What I'm trying to find out is a way for my app to integrate with OAuth2 to keep check if user is still signed in. For example say they refresh the app I need a way to check OAuth2 if user is still authenticated.
Should I use an express server to manage the AUTHORIZATION_CODE returned by the redirect from OAuth2 ?
From what I understand OAuth2 returns a AUTHORIZATION_CODE and STATE in the redirect url.
If so how would I manage this on the express side ? Is there a express plugin to manage this process.
Or could I just bypass using express and just use the Auth0 React SDK to check if user is Authenticated ? I found this example on the auth0 docs. https://auth0.com/docs/libraries/auth0-react
Not sure if this would work because of my setup where the login happens from the client login page and redirects back to my app ?
Authorization codes are meant to be exchanged with access tokens. After you exchanged the code with an access token, what you technically need to do is to inspect the token to check whether it's active or not, with active status meaning that the user is logged in. This can be done in a couple of ways, the following are just the ones I can think of:
Most conventional way I know is to send an API request to the introspection endpoint while including the access token. The response will tell whether the token is valid and/or active.
If the token if in JWT format, it is usually possible to verify the token signature and verify the expiry time after decoding it. Depending on the authorization server, it might be possible to send this token to the introspection endpoint as well.
Unfortunately I can't help with the specifics as the OAuth2 server being used is not mentioned. But if you actually use Auth0 as your authorization server, you can probably use their libraries to help with their OAuth 2.0 flow, such as logins and auth status checks. Otherwise you might need to find another library like node-openid-client or do it manually as explained.
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 want develop few different services (React Apps) with the same users database and Rest API.
Some users might have access to APP 1, some for APP 2, some for both depends on their role.
We decided to go on multiple subdomain apps method.
We want SSO so only one page/app to authenticate all the apps and not a local login component for each app. using JWT mechanism in our backend.
STRUCTURE:
AUTH FLOW:
There are two main problems in this flow which are marked as 1 and 2:
Lets say i go to the login app and log in, getting accestoken from the backend.
How do i deliver the token to app1.company.com? should react login APP redirect with token in url param?
local storage is subdomain scoped.
iframe has problems with Safari.
I don't wanna save jwt in cookies for now because the flask REST can serve non-browser retailed clients.
Lets say the user want to go to app2. if we aren't able to share the token from app1 with iframes or any other method, then this app should be redirected to login and make the process again as app1, which is fine for us.
But is this really the way? if token is invalid anymore and we get Error from backend, should we redirect to the login app in the other subdomain (embed the url we wanna go back to after login success)?
Can i just use 3rd party Open id connect service?
Should i consider microfrontends approcah to make the all the "apps" on the same domain?
How "Attlassian" as an example handles this process?
What am i missing and what is the best way to solve this flow?
Lets say i go to the login app and log in, getting accestoken from the backend. How do i deliver the token to app1.company.com?
It is not a problem that login.company.com delivers the token as a parameter in the URL, because the site can verify the authenticity of the token by verifying the digital signature or with a specific endpoint in the central authentication domain. This is how openid/oauth2 does it using the "implicit" flow, although they also allows to send the token as POST, or use a 2-step flow ("authorization_code" flow)
Lets say the user want to go to app2. if we aren't able to share the token from app1 with iframes or any other method, then this app should be redirected to login and make the process again as app1, which is fine for us. But is this really the way?
You can share the token between domains using an internal iframe, but in your case I would recommend that each domain use its own token.
if token is invalid anymore and we get Error from backend, should we redirect to the login app in the other subdomain (embed the url we wanna go back to after login success)?
Yes, in the number 2) of your drawing, just redirect from app2.company.com to login.company.com and follow the same flow as in 1). You will need some type of cookie on login.company.com to avoid requesting credentials from the user again
Can i just use 3rd party Open id connect service?
Yes, you can use an external OpenIdConnect service, or deploy at login.company.com an OpenIdConnect server like IdentityServer or KeyCloak
Should i consider microfrontends approcah to make the all the "apps" on the same domain?
It is not necessary having a central authentication domain
How "Attlassian" as an example handles this process?
I don't know exactly how Attlassian does it, but currently most web services support OpenIdConnect
I am using JWT and Spring security for user authentication and session management. It is working perfectly fine but I am worried what would I do if JWT will be compromised means I will use JWT of an user from some other system then I will able to access his/her previlages because JWT is not browser specific.
That's why, I want to make my JWT browser specific so that, now onw will able to login from same JWT using another machine.
I searched different way and I found one solution i.e. using cookies, we can differenciate the client browser but I don't think, it will be wise to use session cookies with JWT.
So, please guide me through this, how can I make JWT browser specific?
I'm building a SPA with AngularJS with communication to a Laravel PHP backend. The Authentication method uses JWT, with the tymon/jwt-auth PHP library, which seems to me like a great library.
When user sends his username/password, the service sends back the JWT, which is stored in localStorage on the client. This works fine. However, I want to use a refresh token to continue issuing fresh JWTs to the client, to keep the user logged in as long as he is using the application. Where are these refresh tokens supposed to be issued? Should they be issued when a user sends his username/password? If so, there doesn't seem to be a way in the tymon/jwt-auth library to send the refresh token to the client. Please help, I'm having a lot of trouble conceptualizing how this is supposed to work.
Whether or not you get issued a refresh token when you authenticate with an OAuth 2.0 authorization server depends on which OAuth grant you're using.
When your client is a SPA (an untrusted client), you're probably using the implicit grant and that grant does not support refresh tokens.
Some companies have implemented libraries that are able to refresh access tokens issued by the authorization server using requests in a hidden IFRAME. I'm not familiar with the library you are using.
See also this question for more info.