# Tag Info

5

Second part first: In verify_token the return values are assigned - only to be immediately returned. I get that it might be nice in a debugger(?) but there's really no reason for this - just return the values. I'd possibly create a function that wraps other functions in such an exception handler, but that's probably overkill here. dict.get already ...

4

Are there any security issues? Where should I store the secret's key, DB or InMemory? What's a good 'JWT' Lifetime? Should I send the 'JWT' in Header for every request? What should be done when a 'JWT' Expires? The contents are merely base64 encoded and thus are simple to decode -- so don't encode your valued customers personal data. cut and paste your ...

3

It looks fine to me, I just a few minor suggestions. catch (Exception ex) { throw ex; } You probably left this in by accident, but you're better off without a catch block if all you're going to do is re-throw. And if you are going to keep this block, throw; is always preferable to throw ex; I question the wisdom of having a "default" key specified in ...

3

Run clippy to be automatically told about things like: warning: single-character string constant used as pattern --> src/main.rs:30:40 | 30 | let parts: Vec<&str> = token.split(".").collect(); | ------------^^^- help: try using a char instead: token.split('.') | = note: #[warn(single_char_pattern)] ...

3

There isn't too much to see here because the key generation simply relies on RSA.generate(2048), but I wonder why you would need this code as it is exceedingly shallow. Regenerating key pairs for signing at startup is utter nonsense because a key pair is next to useless if the public key isn't trusted by the receiving party. Exporting the private key as ...

2

Instead of keeping KEY in config, I would keep it with user records. A unique key for each user. I admit, I don't get why creating keys dynamically would break the load balancing scenario. We can have a key created at the back-end where we have a single service serving all the load balances servers (such as a database).

2

No, you are re-rendering the application manually. function ShowSuccessAtDOM(id, name) { ReactDOM.unmountComponentAtNode(document.getElementById(id)); ReactDOM.render( <LoginSuccess name={name} />, document.getElementById(id) ); }; function ShowFailureAtDOM(id) { ReactDOM.unmountComponentAtNode(document.getElementById(id)); ReactDOM....

2

Since this is the backend to a login request, I assume that you expect just 2 inputs, the password and one of the others. So why not use the following: //gets an array of all inputs: email & pass or ssn & pass or phone & pass... $credentials =$request->all(); try{ if(!$token = JWTAuth::attempt($credentials)){ return ...

1

I don't know why an iframe was suggested to you, but I do see some possibilities for vulnerability. For your platforms, I would validate server-2-server. Flow: If client claims to be logged in ( in JS / has token in local storage), send token to the platform itself. The receiving endpoint (let's say platform1_showProfile.php) sends a curl-request to the ...

1

As far as I can tell, This looks like a pretty solid implementation of blacklisting. I can't see any obvious code mistakes. I you are worried about security it can be wise to check the corresponding OWASP documentation This is for Java, but the security considerations should be similar

1

UX concern: refresh period I wonder if you are confusing the access token expiration setting (JWT_EXPIRATION_DELTA) with the refresh token expiration (JWT_REFRESH_EXPIRATION_DELTA). In either case, your t < 13 check should be related to the refresh token expiration, not the access token expiration. 13 seems to be chosen because it is almost 14; hence my ...

1

I'd prefer the filter, just because then you don't have to worry about a missed annotation leaving your API wide open. I never found decoding JWTs to be expensive, and I suspect you're performing premature optimization. value isn't especially descriptive. Perhaps @Authorize(users= would be better. Your code can be simplified by returning early if a match is ...

1

Well , I can give you some suggestions ( though debatable) Log levels has to be chosen properly. I see use of debug in all places. Actually, the info level is good enough to be used for simple texts like LOGGER.debug("INTERCEPTOR-Request post handler----------------------"); . But the debug fits nice , if you have a piece of derived info in log - like ...

1

I can't be of much help with JWT, however if you are able to use es7 features, I would recommend utilising them. const jwt = require('jsonwebtoken'); const expressJwt = require('express-jwt'); const config = require('../config'); const { User } = require('../models'); exports.authenticate = async (req, res) => { const { username, password } = req.body;...

1

Though not in Javascript, my uses of JWT have always used the password as the JWT secret. The JWT payload is whatever you need to identify the user -- username in your case. You can add in a CSRF token of some sort as well. I have an example on my GitHub that is a very simple application using JWT as the authentication mechanism - https://github.com/dave-...

1

Formatting First of all, Go has an official coding style. Use go fmt or IDE tools to format your code! If you happen to be using Vim I recommend the vim-go plugin. I would additionally consider it more readable if the code uses newlines more sparingly, only to separate logically disparate sets of lines. type JWTRequestHandler struct { Secret ...

Only top voted, non community-wiki answers of a minimum length are eligible