How am i able to put the auth tokens i have created into a user state using vuex?
I already am able to place the token into a cookie however need them in user states for individual log ins.
Related
First let me describe the setup:
We have a frontend Angular based product from a different client team (not part of code we can easily modify), and a backend django based API server.
The front end logs in to a keycloak server, and when logged in, the backend gets an Auth header with a bearer token in every request.
From this, we are able to identify the logged in user as follows (using python-keycloak):
ret = keycloak.userinfo(bearer_token)
username = ret['preferred_username']
This is obviously very wasteful since it needs an extra network request to keycloak everytime - so we create a django user session instead and use that for session management.
Now when it comes to logging out, when the user logs out from the front end, we need to void the django session.
I've setup the "Back channel logout URL" on the keycloak realm settings to call some endpoint on the django server.
The endpoint gets called on logout, and it gets a "logout_token" value in the arguments.
Now I'm not sure how I am supposed to identify which user is logging out based on this token. How can this be done?
Thanks in advance...
I am not 100% sure about the soundness of you architecture. Nonetheless, regarding your particular question:
ret = keycloak.userinfo(bearer_token)
username = ret['preferred_username']
From the Keycloak book:
preferred_username This is the username of the authenticated user. You should avoid this
as a key for the user as it may be changed, and even refer to a
different user in the future. Instead, always use the sub field for
the user key.
From the OpenID connect specification one can read that:
OPs send a JWT similar to an ID Token to RPs called a Logout Token to
request that they log out. ID Tokens are defined in Section 2 of
[OpenID.Core].
The following Claims are used within the Logout Token:
iss REQUIRED. Issuer Identifier, (...)
sub OPTIONAL. Subject Identifier,(...)
aud REQUIRED. Audience(s), (...)
iat REQUIRED. Issued at time, (...)
jti REQUIRED. Unique identifier for the token, (...)
(...)
sid OPTIONAL. Session ID - String identifier for a Session. This represents a Session of a User Agent or device for a logged-in End-User at an RP. (..)
A Logout Token MUST contain either a sub or a sid Claim, and MAY contain both. If a sid Claim is not present, the intent is that all sessions at the RP for the End-User identified by the iss and sub Claims be logged out.
So you can try to use the claim 'sub', which is the unique identifier of the authenticated user. You would (probably) need to create the mapping between 'sub' and 'user' in your backend. Alternatively, you could use the same logic but applying it to 'sid' instead. There you would map the ID session of Keycloak to your own ID session.
However, my question is:
The front end logs in to a keycloak server, and when logged in, the
backend gets an Auth header with a bearer token in every request.
From that bearer token (which I am assuming to be an access token) can't you simply get 'preferred_username' (or better the 'sub' claim) from there? that would not require any extra call to the Keycloak server.
I have created a website which allows the user to authenticate against oauth2 (from another provider), the basic flow is (assuming a new user):
The user loads my webpage
An OAuth request token key and secret is provided by the OAuth endpoint
I store the request token into the user's cookies
The user is redirected to the OAuth authentication page from an external provider
The user accepts and is redirected by to my webpage with URL parameters which specify the OAuth verifier and OAuth token
Using the request token (retrieved from cookies) and OAuth verifier (passed via URL parameters), I am able to get an access token key and secret from the OAuth endpoint.
I am now able to authenticate with the providers API and use that to get the logged in user ID.
I then store into a MySQL database, the user ID, a token which I generate as a random unsigned integer, OAuth token and OAuth secret. In cases of the token I generate already being in the database, I just continue in a loop until a unique token is generated. The MySQL database has a strong name, username and password. The database user can only access the table in question and only has privileges to add an entry, delete an entry and make a query.
I clear the request token from the user's cookies and instead store the user ID and my generated token.
When a user comes back to my website, I check if they have the user ID and token stored in their cookies, if so I attempt to look up the OAuth token and secret from MySQL. If they are found, I test they are still valid (does the API endpoint accept them) and if so, the user remains 'logged in' to my website. In cases where the user ID or token isn't found in MySQL or cases where it is found, but is not accepted by the endpoint (expired?), I just go back through the flow above.
The above all works correctly, new users can successfully authenticate, returning users find the website remembers them. I do not expose the OAuth token key or secret to the user and instead, give the user this token ID which I generate.
Are there any problems with what I am doing?
Should I be encrypting the OAuth token key and secret in my database?
Is there a problem with the fact if someone was to gain access to the token I generate, along with the user ID, they would be able to call my scripts. Is this a problem?
Should I be encrypting the user ID and token I generate before storing it in the user's cookies? Taking into account, ultimately whatever is stored in the user's cookies will get passed to my script, so if I were to encrypt, store to cookies, then next time read from cookies and decrypt, the user would still be able to access my endpoints by simply passing the encrypted version (assuming the server decrypts, if the client decrypts then the decryption key would be accessible via the users browser anyway), which doesn't immediately appear to offer any further security.
My goal is to tighten up the steps above so it is deemed robust and secure. The actual use case for my web site means it'll only have a tiny number of users (if any) using it. It was more of a learning process for me, combined with implementing something I actually need. But for the learning aspect alone, I would like to make everything sensible and secure. I am not trying to be overly pedantic and implement steps no other similar websites would implement, basically I would like my site to be secure enough that if there ever was a problem, no one could point a finger at me and say I didn't implement an adequate security system.
I am using django-rest-framework-jwt in my backend and calling API's from Angular Project.
When user try to login on multiple Browsers, each time a new token is generated for the user on new browser. And every token is valid.
What I want is that when user is already logged in in one browser and he/she tries to login on second different browser the previous token for first browser should be invalidated.
In a simple word, NO, you can't just avoid generating tokens unless you made a little twist in django-rest-framework-jwt module. But that's not pure jwt anymore.
JWT stands for JSON Web Tokens and it's a mechanism for exchanging data between computer systems that happens to be convenient for generating authorization headers that can be used to implement statless auth in web apps.
SO
stateless means that you don't track user tokens, You just verify them. If token is valid and the payload is valid, then OK. It doesn't care how many tokens are generated and it doesn't care that they are related to one user. The token is created based on timestamp and will be verified compared to lifetime and timestamp of it.
It means that django rest jwt module, will create a token based on current timestamp of system, whenever user request for it.
Remember you can't delete a jwt token. Because it's not stored in database. So if your token is spoofed, that's it. You can't do anything with it, unless life cycle of the token ends and token expire.
If you want to track these tokens and be able to control them and for example don't create redundant tokens for a user as you asked:
consider changing to another token based authentication that stores token in database so you could track it.
change jwt system to what is suitable for you (I did it before). For example add a lookup id in database and check tokens by that bounded to each user. I know it's not jwt anymore, But you can still use some goodies of it. Like don't hit database on not valid jwt tokens and store some payload in it, if verified don't hit database for that info. Like permissions and ...
So, I have created a django-rest-framework backend with JWT Authentication and now, I am trying to solve the problem where when user manually provides a URL, I have to check If the user was previously logged in.
So since, I am storing the token to localStorage when the user logged in. I am doing this:
componentDidMount() {
if (localStorage.getItem('token')) {
// fetch current user
this.props.ctx.toggleLoggedIn()
// this.props.ctx.setUsername('')
}
}
If I find a token in localStorage, then I have to fetch the current User and then, toggleLoggedIn and also set the current user's username in the context.
So, I am planning to create another API end-point which provides the current user when a token is given. The problem is I don't know how to start that!
It might be that i misunderstand, but for me it seems like you're trying to solve this a bit backwards. When the user login, get token and store this in localStorage. Right after login fetch the user profile and store this as well.
If the user manually provides a url, you should now have both token and user. If you don't have a token or it's expired, redirect to login page and clear local storage.
I would create a higher order component that checks if the token is valid and use this for all "protected" pages.
I want to implement a content based application say based on fetching journals adding to user reading list and first need to check user ip address and then create a login form along with authentication and after that generate a token and the token need to be stored in localstorage and token needs to be accessed till logout