I need additional clarification.
If I got correctly from this link Where Federation authentication token is saved [WIF STS]? and other general WIF-STS discussions, STS token is in default scenario stored in cookie in an browser. In my browser it is split in two cookies started with FedAuth. It is OK. If I understood good, cookie is created by WIF after STS token validation on RolePlayer application. If it is like that, then cookie is in RolePlayer application domain. When user hit RolePlayer2 application (that is in federation and in second domain) then how STS knows about that user, when it has not access to created cookie.
Could you clarify this to me please ?
Refer: AD FS 2.0: How to Use Fiddler Web Debugger to Analyze a WS-Federation Passive Sign-In
You'll see the MSIS* cookies are used for ADFS as opposed to the FedAuth cookies that are used for the application.
So you navigate to RolePlayer2, redirects to ADFS, sees you already have a cookie i.e. have authenticated and mints the FedAuth cookies for that domain/application without asking you to login.
Related
Background
I'm trying implement a browser-based login for a native mobile app from an existing Single Page Application. It uses WebView to render the SPA and it uses Keycloak OIDC as its Identity Provider.
The SPA and IdP is located in completely different domain and authentication is done by redirecting to the SPA domain after a successful login and retrieving the active session (cookie) from IdP domain in one of the SPA's server. The authentication check is achieved by using keycloak middleware which I believe is the protect.js
Summary:
Perform Login -> auth.idp.com
Redirect -> best.app.com
Is Login? -> best.app.com/login
Does auth.idp.com session exists?
User is logged in, redirect -> best.app.com
Token is passed in the URL and is stored only in memory
Token is used to establish WebSocket connection
Issue
Based from the spec, the authorization should happen in the browser / in-app browser, and authorization code must be passed via custom URL scheme. Having that in mind, the SPA that resides in the WebView of native mobile app will never establish a session from IdP's domain since this will be delegated from the browser which is on a different process and obviously using a different cookie store than on WebView in the mobile app, which makes our existing solution to break because it is relying on the IdP's domain cookie.
Proposed Solution
The issue I described above can be mitigated by cutting the reliance on IdP's session and by managing the SPA's own session, which basically means storing the token persistently that can be obtained from the IdP (which the current solution doesn't do).
(I don't want to detail much of the solution since I just want to focus first on the concept of storing the token. I think it's better for me to put this in a separate discussion if someone is interested)
Opinion
It seems like the current implementation doesn't really follow the best practice for OIDC flow but somehow, Keycloak has made some middleware to remove the need to use these tokens (authorization code, id token, and access token)
Relying on IdP's session when implementing SPA or non-web apps seems like not an option, because there is no way to obtain the cookie without reloading the page and provided that IdP session exists in the same cookie store as the SPA.
Redirecting to the IdP's session is not a good user experience for SPA. See the same sentiment here but it seems it does not have any answer: https://lists.jboss.org/pipermail/keycloak-user/2016-October/007937.html
Question
With regards to my proposed solution, i.e., storing the token retrieved from IdP, is there any security flaw or something non-industry standard it's going to introduce? If so, what are those?
Is it typical for OIDC flow to rely on IdP's session (cookie) to check if user is logged in or not?
If answer from #2 is NO, is that authentication flow specific for Keycloak only or does it exists for other IdP as well?
If answer from #2 is YES, is it common for IAM solution to programmatically check if the IdP domain contains a valid session (cookie)?
Is the current implementation flawed knowing we are aiming for SPA?
How does Keycloak handle sessions?
If you're using the default Keycloak middleware in your server and use keycloak.protect() for protecting endpoints, it checks on the request.session['keycloak-token'] which contains the access_token that was created during the token request after user login. If this exist and valid, it means user will not be redirected to Keycloak login page.
How does Keycloak create sessions?
Providing username and password which can be done manually using Keycloak's login page.
Cookies - if you pass valid cookies that are recognized by Keycloak, i.e., KEYCLOAK_SESSION, KEYCLOAK_SESSION_LEGACY, ..., a session will automatically be created.
How to access protected resources?
When using the keycloak-connect client adapters, you can access protected resources if the user agent (browser/app), has a valid session in your server OR if the request contains valid Authorization header.
Standard Solution
Access protected resource via Authorization header and use access_token which the keycloak.protect() also accepts. You can obtain this token in a standard way using Chrome Custom Tabs for Android and ASWebAuthenticationSession for iOS. You can also use AppAuth (iOS, Android) to lessen your work.
Store the refresh_token and access_token from native mobile and inject this in the HTTP request of WebView if possible.
Have a way to check for access_token validity and use refresh_token to request for a new one. If requesting for a new one fails, i.e., the authorization server verifies it's not valid anymore, that means users would need to re login again.
By using the standard solution I have proposed above, you should not need to create a band-aid solution for your issue. Hope this helps anyone that have faced similar issue.
I am using B2C custom policies.
I am using Web.TPEngine.Providers.SelfAssertedAttributeProvider documented here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/self-asserted-technical-profile
The signin relying party of the custom policy is working well, except users won't get user/password challenge after a successful login. I guess the technical profile uses browser cookies like "x-ms-cpim-cache|o4wex_p_gejeeak6w_0" for domain b2clogin.com to remember a successful login for at least a browser session.
The Metadata "setting.enableRememberMe" is the default that is set to false.
I need to make sure users are challenged with user/pwd every tinme the signin relying party is called. Is there any way to disable the auto-login with the cookie cache?
Set the session management technical profile to SM-Noop on the sign in technical profile.
For JavaScript apps, this will break silent token calls for an access token.
Other option, for initial logins, send the query param prompt=login which will kill the cookies when the user arrives at B2C. This at least keeps silent token calls working for JS apps.
Hi I am trying a simple authentication of a webapi using AzureAD. In that when we add the connected services using the Azure AD, the Startup.cs class adds the below code
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Tenant = ConfigurationManager.AppSettings["ida:Tenant"],
TokenValidationParameters = new TokenValidationParameters
{
ValidAudience = ConfigurationManager.AppSettings["ida:Audience"]
},
});
When i went through some of the authentication tutorial, i am seeing people are asking to use some thing like the one shown below
app.UseCookieAuthentication(new CookieAuthenticationOptions());
app.UseOpenIdConnectAuthentication(
new OpenIdConnectAuthenticationOptions{....
}
What's the difference between these 2, aren't we supposed to be using AzureAD options going by the name and since we are using the AzureAD Connected Services for Authentication of the webApi. Can some one clarify the same?
Cookie Authentication
Cookie authentication uses HTTP cookies to authenticate client requests and maintain session information. It works as follows:
The client sends a login request to the server.
On the successful login, the server response includes the Set-Cookie
header that contains the cookie name, value, expiry time and some
other info
The client needs to send this cookie in the Cookie header in all
subsequent requests to the server.
On the logout operation, the server sends back the Set-Cookie header
that causes the cookie to expire
Note: Cookie authentication is vulnerable to Cross-Site Request Forgeries (CSRF) attacks, so it should be used together with other
security measures, such as CSRF tokens. For more details you could take a look here
Azure Active directory Authentication:
As you know Azure Active Directory is a modern Token based authentication which provides Single Sign-On (SSO) that allows a user to use one password (or smart card) to authenticate to multiple servers on a network without reentering credentials. This is an obvious convenience for users, who don’t have to remember multiple passwords or keep going through the authentication process over and over to access different resources.
Main thing is AAD uses JSON Web Token(JWT). On receiving the credentials from client the server validates the credentials and generates a signed JWT which contains the user information.
Its also support most popular modern authentication protocol as following.
OAuth 2.0
OpenID Connect
WS-Federation
SAML 2.0
Note: the token will never get stored in server(stateless).
So the main difference is cookie based authentication usually stores your user sensitive information on server because it maintains session which seems vulnerable on the other hand token based authentication is secure and don't preserve sensitive information.
see the basic difference of these tow architecture below:
Select Right Authentication:
Here I am showing you a flow chart which enhance your idea to choose right authentication for your application. Take a look below:
You could also have a look here for better clarity. Thank you very much. happy coding!
When you login to Identityserver the authentication cookie idsrv is stored in the browser. When the user logs out, the cookie is deleted. However, an attacker can steal the cookie and essentially use it even though the user has logged out.
This seems to be "normal" behavior for many identity providers too.
Question
Is it accepted behavior?
Is there anyway to detect that the user has logged out and that the idsrv cookie value (token) is no longer valid? Should we for example implement IAuthenticationSessionValidator to keep track of the users that are signed out? Or is this something that should belong to the application by using the id_token session_state claim?
According to OWASP ASVS requirement 3.2 Sessions should be invalidated on user logout it should not be possible to use the same cookie after logging out of the application. This also is the case if using other identity providers like ADFS and AAD.
I have some webserver resources protected with Form based Authentication. The requirement is to have some highly secure resources access result in forced authentication of the user even if he/she is authenticated earlier and have a valid cookie (authentication).
The authentication in a session is maintained by a particular cookie. The first idea to solve this problem is to pass that cookie with "expires" value with back date. But for the form login it is not working, I am getting only login page everytime after providing correct credentials. Cookie with expire value with back date is encountered, cookie is deleted by browser. So this cycle of login is encountered.
Please advise me on what to do.
At this point authentication isn't enough. You're going to have to implement multiple levels of authorization, with some levels not having persistent tokens. There's a number of resources on the Internet that explain token-based auth.
Basic authentication (not to be confused with the HTTP scheme of the same name) uses only a single token to determine whether the user is logged in or not. Just split the application into multiple authz token realms and handle it from there.