I am using WSO2 Identity Server 4.1.0 to perform basic authentication. It is possible to call the AuthenticationAdmin webservice, which contains a 'loginWithRememberMeOption'. The user will then obtain a 'rememberMeCookie', with which he can log in, even if his session (JSESSION) has expired.
I have learned that the loginWithRememberMeOption also has a timeout: 7 days, and that this time cannot be modified: WSO2 Authentication, adding/modifing timeout to the RememberMe cookie
The AuthenticationAdmin service also provides a 'logout' operation. Unfortunately, this operation will only invalidate the session. So if a user has a rememeberMeCookie, he will still be able to login: WSO2 AuthenticationAdmin Logout
The question is, how do I logout a user that has obtained a rememeberMeCookie? Preferably using the AuthenticationAdmin?
As I understand there is no direct way to logout a user with a remember me cookie.
I went through the code. Once you login with remember me option, a UUID is generated. Refer org.wso2.carbon.core.services.authentication.AuthenticationAdmin.loginWithRememberMeOption(String, String, String) method in AuthenticationAdmin
The cookie is then saved in database. When you login with remember me cookie, the cookie is checked from the user store. Refer org.wso2.carbon.user.api.UserStoreManager.isValidRememberMeToken(String, String). You can check the JDBC implementation.
So, in order to logout, you might have to clear the cookie from the user store.
Please report a JIRA issue, if you think it might be useful to add a method to clear the cookie.
Related
I am creating api using cakePHP. I have created an api for user log in. This log in functionality is working fine.
Here is the log in function -
public function login(){
if ($this->request->is('post')) {
$user = $this->Auth->identify();
}
}
Now, the I am facing problem is, how I can test from other api that is the user is logged in or not? In web application it can be done by default auth system ($this->Auth->user()). But I am not getting how I can check is this user logged in or not from another api. Do I need to send api parameter to each api request ? or any other suggestion ?
Note : I can't send any token in header. Because in header I am sending jwt token. Because in my application there are two kind of authentication. One is log in or not? and another one is depending some other input from user. That is handling by jwt. So jwt token I am already sending by header. So header is already used.
A couple of things to clarify.
In a regular app, the user logs in with a post request and on successful authentication a session is created. This session is a bit of information that the user supplies in each of the following requests and the server then recognises the user. This accomplished by the Auth component in it's default settings.
In an API you could do the same: the user logs in, receives the session and attaches the session cookie-like object on each following requests. (Example of such a Python client.) However, this is not considered good practice as APIs should be stateless (so without requiring something like cookies). The solution of working with tokens, for instance hashes of some secret token together with a timestamp. The Auth component also supports this pretty well. After setting it up, you can simply call $this->Auth->user(), like you would normally and it returns either false or an array of user information. See link below.
Note that by default this authentication type will block unauthenticated users, so you will never see ->user() return false unless you make pages as public.
See also:
(Cookbook > Authentication > Creating stateless authentication systems)
I am having a HTML (Angular) site which has a login button and needs (of course) to present a different GUI when the user is authenticated. I am using ServiceStack based REST services. Now when a user is successfully authenticated I was wondering if it is possible to check the generated authentication cookie (by ServiceStack) on the client only. I just need to check the userid, maybe role and expiration date of the cookie. Advantage is I do not have to make 'CheckUserIsAuthenticated' server rest call's just for showing a different GUI (of source CRUD actions are validated serverside).
You can check that a cookie exists with document.cookie, as it's hard to work with directly Mozilla provides a lightweight cookies wrapper to make it easier to work with, likewise AngularJS provides $cookies provider.
But a cookie doesn't tell you anything about the user since even non-authenticated / anonymous users will have cookies. Instead to check if the user is authenticated you can call /auth route via ajax which when authenticated ServiceStack will return summary info about the user, e.g:
{
UserId: "1",
SessionId: "{sessionId}",
UserName: "user#gmail.com",
DisplayName: "First Last"
}
If the user is not authenticated /auth will return 401 Unauthorized.
I can not seem to find a SIMPLE answer to the question on how to persist OAuth2 authentication... Let's take Google+ OAuth2 API as an example.
User goes to page
User is not authenticated, and gets redirected to authentication page where he logs in
User logs in successfully and authorises my app
User gets redirect to specified (by me) URI with Authorisation Code
I use authorisation code to obtain a token in order to submit queries in the name of the user
All is good and well. My question is: how do you SECURELY know at step 2 that the user visiting the page is already logged in, without having to go through the whole process of redirecting him to all these pages.
I assume storing the Authorisation Code retrieved at step 4 in a cookie is not an option.
All of this will happen in a server-side (Go - if that matters) application.
Any help is much appreciated... I need a simple solution.
Thank you!
use server-side sessions to store any authentication state or even access tokens if you need them.
one solution is to use a database for session store (an encrypted cookie holds the session id)
and another is to use cookie sessions (encrypted cookies that hold the session data).
using encrypted cookies that only the server is able to decrypt should be safe enough.
I'm trying to implement a way to actually logout from my application that is using the Valence API. I can obviously clear the session on my end, but is there a way through the API to actually log out of the Desire2Learn site as well? I've looked through the docs and didn't see anything.
No, there is currently no route to explicitly log out, or log in. You can, however, use the Valence auth process to generate credentials for a new user. What you need to do in that case is use a browser to interact with the user that doesn't have an open session with the LMS: as long as the LMS thinks that the browser doing the user part of the authentication has an open session, it will pass back the user credentials for that user instead of asking the user to re-authenticate.
Typically an inactive session with the LMS expires after a short time and then the LMS will force the user to re-authenticate if your app initiates the auth process.
I'm trying to implement simple password-based authentication for a web application written using the Happstack framework. My user presents an ID and password, which I hash using bcrypt and check against by database. If the hashed password is in the database for that ID, the user is thereby authenticated.
Once I've authenticated the nice user, I would like then to issue a session cookie which marks that user has being logged in for the duration of the session. (I am not trying to implement a "persistent", "remember me" sort of cookie; I am just trying to find out if the user is logged in for the session.)
Is the presence of the session cookie alone sufficient to authenticate the user?
If not, what other information is needed? I could store the cookie's (hashed) value in my database, but at this point, I don't see how what I would be doing would be much different from a persistent login cookie.
In short, is it possible for me to use a session cookie to identify an authenticated user, and if so, how should it be done?
(I have been able to learn how and why to mark the session cookie as "secure" and "HTTP only", but I can't figure out what to do with the darn thing!)
You can use happstack-authenticate for an existing solution to password logins. If you still want to roll your own however you'll want the happstack-clientsession package for session cookies that the user can't read or write. A normal cookie marked "secure" only means it only works over HTTPS, but the user can still both read and write the cookie. With clientsession the cookie will be encrypted with a server-side key. You can use clientsession both for "remember me" and session logins; it simply depends on what you set the sessionCookieLife to. The default if you use mkSessionConf is Session which is what you want.