I'm using ServiceStack Authentication to authenticate, and using http to do so. This might be duplicate to my previous post, but this is another question. When I'm sending a post-request auth/logout the request header doesn't have session-id which doesn't logout the user on the other website.
How can I send a post logout request that log the user out from all the web site that he/she is logged in?
How can I send a post logout request that log the user out from all the web site that he/she is logged in?
In order for a User to be logged in they need to be sending ServiceStack's ss-id/ss-pid Session Cookies. If the HTTP Request doesn't contain the Session Cookies it's treated as an anonymous request and sending a logout request wont have any effect. But in most cases you would just use the same HTTP Client used to authenticate the user, to log them out as they'd automatically also send their Authenticated Session Cookies with every request.
Other ways you can send ServiceStack Session Ids is to send Session Ids as HTTP Headers with the X- prefix, e.g:
X-ss-id: {sessionId}
X-ss-pid: {permSessionId}
X-ss-opts: ...
Or if you enable the AllowSessionIdsInHttpParams option in your AppHost, e.g:
SetConfig(new HostConfig {
AllowSessionIdsInHttpParams = true,
});
You can also send the Session Ids via QueryString, e.g:
/auth/logout?ss-id=...&ss-pid=...&ss-opts=...
Related
I successfully authenticated my user with my firebase app in the browser. Now I want my custom backend to know that the user is authenticated.
How do I go about this? Can I tell the client to include the firebase JWT in every request to my backend, so that the backend knows the user is logged in? (This is necessary so that the backend will not redirect a logged-in user to the login page, for example.)
Background Research:
The firebase authentication docs explain how to get the firebase token, send it to your custom backend, and then do something on the backend with the user data. That's fine for an XHR request, where you can tell the browser to include the token as a header. I don't understand how to get the browser to include the token in a normal HTTP request to the server, like when the user opens a new tab and navigates to the admin panel at https://example.com/admin.
This is a related question, but I didn't understand the answer (or at least how I could apply it to my use case).
Here's how the good guys at jwt.io explain it:
Whenever the user wants to access a protected route or resource, the user agent should send the JWT, typically in the Authorization header using the Bearer schema. The content of the header should look like the following:
Authorization: Bearer <token>
This is a stateless authentication mechanism as the user state is never saved in server memory. The server's protected routes will check for a valid JWT in the Authorization header, and if it's present, the user will be allowed to access protected resources.
I would like to set up a mechanism to track every user http session based using a Cookie object. Therefore I store the user ID in a Cookie which I will communicate then to the client in the response body (once the login process is successful) such as :
Cookie loginCookie = new Cookie("userId", userId);
httpServletResponse.addCookie(loginCookie);
I have a got three questions please :
1) How to retrieve a given user http session based on his Cookie ? Shall I store the JSESSIONID instead of the userId for this purpose?
2) Encrypting the user cookie won't prevent the cookie from being compromised by some attacker eavesdroping the communication between the client and the server. Thus the attacker could reuse the cookie to request the server as being the actual user since the same cookie is being communicated each time the user requests the server. I don't really see where encrypting the cookie could help. Shall I use a digital signature algorithm as well in order to authenticate the sender?
You should store the session ID in the cookie, and the user ID in the server-side session.
Cookie re-use should not be an issue if you are using https, which mitigates the risk of eavsdropping. If you are not using https, no manner of encryption will help you.
Description
In my mobile application, the user tries to access a resource which requires authentication.
After logging in and obtaining the access token, I want to redirect them to the originally requested page (the return Url).
Question
In a token-based authentication, how to redirect to the return url?
Example
Consider this scenario:
1 - I have a menu in my mobile application "My Profile" which opens a WebView and navigates to mycoolwebsite.com/myprofile.
2 - The server (MVC controller) redirects to a Login Page with the returnUrl as in the URL. mycoolwebsite.com/login?returnUrl='/myprofile' because user cannot access mycoolwebsite.com/profile without logging in.
3 - User sees a Login Page, they enter their username and password, and press the Login button.
4 - A POST request will be send to the _Token Endpoint _ of the ASP.NET application, including username and password and grant_type of password
5 - The server validates the credentials, and issues a Token. It will send the token back to the client as a JSON object.
Problem: after obtaining the Token, I need to redirect the user back to mycoolwebsite.com/profile which they originally requested.
In an ASP.NET MVC application, this happens automatically with the MVC template.
However in WebAPI, I'm not sure what is the proper way to do this.
With Cookie Authentication it works like this:
User submits the login form, making a POST request to mycoolwebsite.com/login?returnUrl='/myprofile'
The server authenticates the user and if the authentication is successful it returns 302 Redirect response with Location and Set-Cookie headers. Location header contains default redirect url (usually "/"), or value from returnUrl parameter (in this case "/myprofile").
Finally the browser sets the authentication cookie and then redirects to the new location.
Bearer Token authentication (most likely your case)
The user fills the login form and make an Ajax request to mycoolwebsite.com/token
If the authentication is successful the server replies with 200 OK status code and returns the accessToken.
The client then reads the response body and store the accessToken for further use. Now it's up to you. You can read the returnUrl parameter from URL and redirect user to mycoolwebsite.com/myprofile.
So the difference between these two is that the redirection occurs on server-side (via 302 Redirect response) or on client-side.
Hope it helps.
We are trying to implement Single sign on (sso) using SAML 2.0 using ADFS with our customer site.I have successfully set up ADFS and when i access ../adfs/ls/idpinitiatedsignon.aspx page it shows "Sign in to this site" radio button and it redirect to customer site and asks for Username and password and once entered customer's site user name and password then it brings back to idpinitiatedsignon.aspx and says "You are signed in" and shows sign out button.But i'm unable to get the logged in user's details from HttpContext.Current.User in idpinitiatedsignon.aspx because HttpContext.Current.User.Identity.IsAuthenticated is false but IsAuthenticatedis true. So how can i get the logged in user information ?
Because when you call FormsAuthentication.SetAuthCookie(txtUsername.Value, true); you store the key on the client's cookies. For this you need to do a response to the user. And for HttpContext.Current.User.Identity to be filled with cookie you need one more request.
In short your scheme looks like this:
Client sends his UserName and Password.
Server gets and checks it.
If they are valid the server sends Set-Cookie header to the client.
Client receives and stores it. For each request client sends cookies back to the server.
I am using oauth in my web application to access Twitter. My problem is i am not getting the token secret and moreover when i run my application it asks the user for authorization request. when the user click "allow', it does not go back to the called url. Infact it shows a blank untitled page with a url having oauth _token value and oauth_verifier value.
Can someone throw light on this.
Before you send users to twitter.com to authorized the app you need to save the request token secret. When the users clicks allow they will return to the callback url you specify. Once there you need to use the request token/secret to get an access token from twitter that will let you perform API requests as a user.
http://dev.twitter.com/doc/post/oauth/access_token