I am developing an application where clients will receive the broadcasts from the server. I am planning to use nodejs, express and web sockets. I'll be using jwt refresh token with jwt auth token for authentication and authorization. I have prepared a mock for my approach.
Post successful login, I'll be providing an auth token with expiration time as 5 days and an access token with expiration time as 120 seconds. All the resource's access is granted based on the access token.
The client will be calling the rest server's token api to refresh the access token every 90 seconds and will update it in local storage.
Server : https://codesandbox.io/s/websocket-server-sygp1
Client : https://codesandbox.io/s/websocket-client-8b356
Is this the correct approach for authorization with websockets?
I have searched a lot for refresh token authorisation using WebSocket but haven't found anything concrete, so came up with this approach.
Related
Last couple of days, i spent on an issue that how could i secure my jwt access token at client side (browser). Some blogs say that Local / Session storage is not secure to store the token. I moved to store the token in ngrx store but there is another issue that when user refresh the page, he/she must re-login to get the token again. Third option is cookie, a secure and http-only cookie.
Where to store my jwt token to secure it?
Note: In backend, a spring boot api is running which sends a token on successful login.
I started working with instagram APIs using node.js and walked through the official instagram API docs here but it does not explain clearly.
Here I have 2 questions:
what is the difference between Client ID and Client Secret?
what is access_token ? and what is it used for ? and
when we should request for it ?
The client ID is is basically a unique id assigned to your application by an Oauth provider. It considered public information, and is used to build login URLs, or included in Javascript source code on a page.
An app requesting an access token has to know the client secret in order to gain the token. This prevents malicious apps from ever obtaining a valid access token. The client secret id doesn't state anything about authenticating a user, but it's instead for authorising an app to request access tokens.
The client secret must be kept confidential. If a deployed app cannot keep the secret confidential, such as single-page Javascript apps or native apps, then the secret is not used.
When you login with an Oauth provider, the server responds with an access token and expiration time in ms if the login is successful.
{
"access_token":"RsT5OjbzRn430zqMLgV3Ia",
"expires_in":3600
}
Every time client requests a resource from the server, the server validates the access code. The access-token is used to verify every request from the client. You will request for an access_token whenever you login through an Oauth provider.
You can refer this and this for more information.
I'm using Oauth2 to handle authentication in my system. While the authentication works, I'm worried about the security of my refresh token endpoint. The front-end calls this endpoint to get a new access token after it expires.
My question is how would you prevent someone from calling that endpoint and getting a new access token? Would you use the access token to authenticate yourself? At the moment I'm using these tokens to authenticate API calls on a separate service.
The endpoint currently supports csrf, but that's probably not enough.
Thank you!
The refresh token is used to get the new access token. That is where the authentication happens.
You can decrease the time that a refresh token is valid.
You can also choose if you want the refresh token to be renewed or not with each call to refresh the access token.
Unauthenticated clients cannot call the refresh token endpoint and get a new access token.
I have questions related to non interactive clients like backend apps based on oauth2 flow.
https://auth0.com/docs/api-auth/grant/client-credentials
In accordance with oauth2 for non interactive clients, flow is :
The application authenticates with Auth0 using its Client Id and Client Secret.
Auth0 validates this information and returns an access_token.
The application can use the access_token to call the API on behalf of itself.
Base on this, my questions are :
Backend applications should store the access_token locally or request a new access_token for the same client each time the client uses the application?
If access_token is stored locally what happend with expiration time?
Access_token for non interactive clients should have the same expiration time compared with access_token for interactive users (login web) ?
Backend applications should store the access_token locally or request
a new access_token for the same client each time the client uses the
application?
For client credentials grant flow, the decision whether to renew frequently, or "cache" a returned JWT Access token will depend upon your requirements - if scopes for example change frequently, it may make sense to fetch a new access token frequently to ensure those changes are reflected. Speaking from personal experience, this generally isn't the case, so caching the token for the duration of its expiration makes sense, and saves an extra call to Auth0 to fetch a new token with each request.
If access_token is stored locally what happened with expiration time?
You can choose to check the expiration before making a request each time, and fetch a new access token if expiration has elapsed, or else just attempt to use the access token without checking, and then try renewing only when you receive a failure when using the existing token.
Access_token for non interactive clients should have the same
expiration time compared with access_token for interactive users
(login web) ?
Similar question to the first one. Since using Client Credentials grant flow usually indicates confidential / trusted client (you are storing a client secret) - and frequently for machine to machine scenarios - it may make sense to use a greater expiration time. However, as already mentioned, if scopes may change etc, then a short expiration would result in configuration changes (scopes) being picked up faster.
I'm writting a toy application for practicing microservices and authentication on nodejs (expressjs).
I have a react client, an authentication service and other services (they just respond "Hi" so far).
The client will be hosted in a CDN.
The auth service listens on port 5000 (for example)
The rest of the services listen on port 6000-6100.
I have a redis db to store session information (oauth token provided by twitter).
A mongodb where the application information is stored (not relevant for this question).
The idea is that an unauthenticated client goes to the auth service by clicking the Twitter button (SSO). Then the auth service obtains the generated twitter oath token and it sets this token in the redis store. Then the token is accessible to the rest of the services so they know if a request is authenticated or not by checking if the it already exists in the redis store (if the user removes its account, it will also be deleted from the redis store).
I send the twitter token back and forth from client to server once authenticated.
I find this approach pretty simple (others use an nginx proxy for authentication but I see no reason for that, except if the services are hosted in different domains, but I don't understand it very well) so I'm worried I'm missing something about security for example.
Questions:
Is this approach correct?
Is it safe to share the twitter token (I think so)?
Is there any security issue I'm not noticing here?
Using this approach you will have to validate the token in all your services, if you are okay with this then you are probably fine.
The twitter access token may have an expire time that will make it necessary to use a refresh token to get a new access token from the auth service:
When the access token expires you would return a 401 to the client, from the Service X that you are trying to talk to.
The client would have to call the Auth service providing a refresh token, getting a new access token
Finaly the client would be hitting the Service X again with this new access token, have it validated and get the expected response from Service X.
In my recent assignment I wrote a micro-service that proxied all the tokens, using this approach my proxy handled everything from auth to roles and sending 401's for expired tokens and revoking refresh tokens etc. I think this gave me a greater separation of concerns.
Important Note: In the refresh token scenario above my proxy only would experience load for an invalid/expired accesstoken, whilst in your scenario any service could be reached with invalid tokens...
Another approach would be to let Service-A and Service-B call the auth service to validate the tokens, but this would infer a lot of more traffic between the services since each HTTP request with a token has to be validated. In this scenario as well a invalid token request would reach your Service X and hence infer some load on it...