I am developing an angular app which currently has authentication with cookies and session. But I want to use jwt authentication.
And I have a doubt that if that token is stolen then the complete authentication is stolen?
And If there is no expiry date is that a risk?
Because if I login in my computer then the token always resides in the browsers local storage and if anyone steals that token from my computer, they have the access to my account. Then how is it a secure authentication
Please help me in understanding the risks and the way this works.
Thank you
Yes, in the absence of the exp (expiration time) claim and if your token is stolen, you will have a serious security problem.
This can be mitigated by the audience if a jti (token ID) claim is set, but necessitate a storage (e.g. database, and filesystem...) with all revoked jti.
As per OpenID Connect Core Specification, ID Token must have an exp with usually no more than a few minutes.
I think that all authentication providers that use JWT should follow this requirement.
Related
Snowflake supports caching browser-based SSO authentication using an ID token. Any idea how long this token is valid for? I can't see any mention in the docs.
At least a cached MFA token is valid up to 4h.
https://docs.snowflake.com/en/user-guide/security-mfa.html#label-mfa-token-caching
I'm using the adal-angular5 v1.0.36 client library to authenticate my web application to Azure Active Directory.
The thing is that my session lasts 1 hour (the default expiration time) and I'd like to "renew" it silently for the user once it has expired; i.e. without having to ask the user for the credentials again or logging out and then login again (which would cause work loss for the user).
Is this possible to achieve?
As long as the user have an active session with Azure AD, ADAL JS does it automatically for you. ADAL JS examines the projected expiration of the existing token (in the cache) and if the token is about to expire, it uses an invisible iFrame to send a new token (renewal) request to Azure AD.
Please choose MSAL over ADAL and here is the sample for angular using MSAL.
Please refer the link for migration of ADAL to MSAL
For now I have Asp.Net WebAPI and client application (Angular) on separate hosts. As for authentication, WebAPI uses default external OAuth provider (Google) implementation with middlewares, external bearer token and cookie. Since web application is being hosted separately, for security reasons it is using Implicit grant flow, so access_token is being returned after hash symbol in URI. Also, it means that refresh token can not be implemented.
Here comes the part I am a bit confused about.
As for my WebAPI I am using Local accounts, which have to be created for every new user that comes to my application externaly (from Google) using basic information it provides. So the external bearer token and cookie are only used till I register the user, sign him in and provide LOCAL AUTHORITY bearer token which can be used to access secured API endpoints. It means I still have the LOCAL AUTHORITY provider which lives in my WebAPI and manages access_tokens.
Does it mean that I can implement refresh token?
If I understand correctly refresh token is not valid between Google and my app (because it is using implicit grant flow), but it is viable between my WebAPI and Client application without leaving security holes?
I am a bit confused about the refresh token here. Is it possible?
Thanks for your time.
Kind of Solution
Read this answer for the solution
I have a web application that uses "htps://mail.google.com/ email profile" endpoints/scopes for OAuth2 to integrate with Gmail's IMAP. According to the following news:
http://googleappsupdates.blogspot.ro/2015/12/increased-account-security-via-oauth2.html
https://support.google.com/a/answer/6328616
tokens will be revoked for certain applications on password change. The main use-case is to address the problem of lost or stolen mobile/desktop devices. This should not affect web applications otherwise it would ruin a big part of OAuth concept. But it is not clear from the news whether web applications will be affected or not. Could somebody clarify this please: Will OAuth2 automatic token revocation upon password change affect web applications?
Depends on how you are using OAuth 2.0.
If you have a Refresh Token, I am assuming, Google will no longer accept that token.
You application should detect that the Refresh Token is not valid and perform actions to allow the user to Authorize your application.
This may require you to notify the user out-of-band of OAuth as they may not be online at the time your Refresh Token fails.
This question has come up a lot but I haven't discovered the answer. I've read the OAUTH 2 spec and the separate security "considerations" document but I'm still fuzzy on something.
The circumstance is: RESTful based web services being accessed by mobile applications. I am both the server resource (creator and host of the RESTful services) and the authorization authority (I store the user's IDs and passwords and validate identity). Third party companies create the mobile applications that consume my services. I am using OAuth 2.0 to validate the user's UserID and Password and issue a token. TLS via https is used.
A nonce with a singed message is commonly used to prevent against replay attacks but as I understand it, that won't work in a mobile application because in order to sign a message, you need a shared secret. Any secret stored on a mobile app (that would allow you to sign messages) is no longer a secret. So a nonce can't be used.
So we have session tokens, which expire after some configurable period of time, and can be refreshed with a "refresh token".
My question is: If TLS is defeated (example: user is dumb enough to connect their mobile phone to a proxy server and install a certificate of the proxy, which then allows the proxy-server owner to read the unencrypted traffic), what prevents a hacker from replaying a request with a valid session token (while it's still alive), or worse, persisting the session for hours at a time using the refresh token to continuously obtain new session tokens?
The situation you suggest is one where the security is defeated and there is no security. The proxy can do things like steal the user's password during authentication or divert the access token to another application (either local or remote). You must just accept this scenario as a loss.
Also, it is typical for mobile apps to have a shared secret. As you point out, the secret loses some security being on the client, but it is still better than nothing. The secret is typically encrypted while at rest to prevent it from easily being stolen. Of course, the decryption key can be stolen from the app even when obfuscation techniques are applied to it but it provides some security.
Be sure to restrict the access rights of the secret on the client. Make sure that it is not configured for 2-legged auth. That should be saved for servers and only when needed.