We are using C# MVC with Entity Framework and custom authentication implementing OWIN to make authentiation available by a custom user database.
Users login and authenticate themself by username and password by a standard login form.
To fit common security messurements OWIN regenerates the ".AspNet.ApplicationCookie" on each login and logout, I also force the "SessionIDManager" to regenerate a new Session ID (saved in .AspNet.ApplicationCookie) on each authentication change.
We use QUALYS to test the application for well known attack scenarios such as XSS, Session Hijacking etc. One imortant technic is to issue and validate Antiforgey Token which will be placed inside the form field AND inside a cookie stored on the client. As I unterstood these do not have to match since they are encrypted and get verified after decrypted on serverside on POST request (with ValidateAntiForgeryToken Attribute).
As mentioned above we use QUALYS to cover possible vulnerability scenarios. The report mentioned a security issue with the "__RequestVerifiationToken" which is set in the cookie and will not be regenerated until it gets invalidated by time. I reproduced this by tracking the traffic with Fiddler.
So the Token are there, get verified and I can log in, log out, chagne password and so on.
My question is, is there a build in possibility to reissue a __RequestVerifiationToken for the cookie?
When using the HtmlHelper #Html.AntiForgeryToken() it regerenates a new token for the hidden form field on each reload, but the cookie value keeps the same over time. I need to regerenate the cookie __RequestVerifiationToken value as well, at least on login / logout actions.
A side question is why internet explorer (Edge) requests result in a long time request when I manipulate the hidden form field content, firefox instead gets the error that a AntiForgery Erros occured?
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'm developing a web application and I'm having difficulties in implementing a log in feature.
In my application, a user has to log in to add a new item(row to a database and corresponding user id is added to the newly created row). Also, the user can navigate to different pages in the application, which all requires the user to be logged in. So, once the log in is successful the user id can be stored in a cookie file to share it with all pages. But I realized that, an user after using his credentials to log in, can then alter the cookie file and change user id in the cookie to someone else's and then view confidential data of the another person. How to prevent this type of attack ?
PS: I'm using servlets and JSP for my app.
An approach would be to, instead of storing the user id in a cookie, store an authentication token in the session cookie; this token needs to be unique per user and very difficult to guess. For this you could hash and salt the user id to generate the authentication token.
For extra security, make sure that the token expires at the end of the session or after the user logs out.
It would also help to do this over HTTPS, so that your traffic is encrypted.
Here is a very good guide to web based authentication.
I have been through much of the documentation and examples provided, but Im looking for some inputs for my setup from other users.
I have a some clients (website, iOs/Android apps). These only serves as a shelves and its content will be requested through servicestack, which makes servicestack a central point of my setup.
The client will login through servicestack and get a sessionid.
My question here is, how should i setup servicestack to make sure that the user is validated on each request?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted). Then on each request based on the session id, i check the cache to see if the user exists. If the user exists, the request i authenticated, and if not the user have to login again.
Am i on the right track here, or is there an easier way in servicestack, to support this?
I was thinking after login, i save the user in the cache and make sure this expires after some time (unless persisted).
It sounds like you can just use the Authentication/Authorization plugin. Once a user is authenticated (using any of the 'Providers') the user's session is stored in the cache using the key 'urn:iauthsession:[sessionId]' and contains a bool property isAuthenticated. For any Service the requires Authentication you can use the Authenticate attribute.
I have developed simple website using Tomcat and Java. Now I'm trying to add authentication to it. I am storing username and encrypted password in database.
How do I validate user on every request to website?
While doing my research I found out that I need to set some cookie, return it to browser if user is authenticated, and then validate it request by checking this cookie in every request I get from user.
Also, how do I manage the session, i.e. create new session for user upon authentication, set timeout, clear session and cookie upon logout?
Web development and particularly authentication/user management is very new to me, so I will appreciate your help.
Thanks.
This will depend a lot upon the language you are using to develop the website and how you plan to handle sessions.
PHP Sessions
Java (JSP) Sessions
ASP.NET Sessions
ASP Sessions
...etc
the list goes on, especially with how to manage authenticating.
The general (pseudo code) for this usually revolves around something of this nature
Depending on the language of course:
User Creates Account (typically an HTML form posting to your server side code)
Account Information Is Stored to the database
Cookie is created with information allowing user to auth in the
future (with cookie duration)
Session is created for the duration of the users login
User leaves the website
User comes back to the website
Website checks for stored cookie
if Cookie is found - check cookie, is the auth still good? (did the
users password change recently? has the cookie expired)
If the cookie is good - create a new session and allow the user into the website
If the cookie is bad - present the user with a login form
Rinse/repeat as the user logs in and out.
Depending on your language you will want to look at different resources, however cookie generation is a pretty simple task and can be easily done with JavaScript and HTML. Take a look at http://www.w3schools.com/js/js_cookies.asp and see if it meets your needs. Note that from what I recall JavaScript only does Cookies, and not sessions.
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.