how to do upwork authentication process triggered by azure function? currently its OAuth 1.0 process to get verifier, but how to achieve it without asking verifier each time.
you don't need to ask for a verifier every time, It's enough to authenticate a user once, receive an access token/secret pair, keep them in a safe place, and re-use to sign all next requests. It is mentioned here -
https://support.upwork.com/hc/en-us/articles/115015933448-API-Authentication-and-Security
Note that OAuth Request token expires in 600 sec. Once the Access
token is created it never expires.
Simply put, you don't need to go throw the authorization before every request. It's enough to complete it once for a particular user.
Related
Let's say we have short-lived access token (15 minutes) and long-term refresh token (7 days).
When should we ask backend to refresh access token?
I see two options:
After user logs in we start a countdown to automatically refresh token one minute before access token expires.
We don't implement timer and we try to refresh access token ONLY if we get 401 response from backend.
In first option I see one advantage -
if access token and refresh token will expired AND user stays on the page, not taking any action, he also doesn't send any http request than the timer still works and user is logged out automatically.
In second option -
if access token and refresh token will expired user will be logged out ONLY if he will make some action on page for example: leave a page or make a http request.
If he will stay on page he won't be logged out automatically.
What is a better implementation on frontend than?
I would recommend option 2 as your default behavior, since it will give you a resilient app. Every OAuth client should do this, since 401s can sometimes also be received for infrastructure reasons in some setups, eg token signing certificate renewal.
Option 1 is an optimization, if you want to reduce 401 responses from APIs. However it can lead to incorrectly developed clients and APIs if you are not careful. Personally I never use it.
Note that an expires_in field is returned with the access token but there is no equivalent field for the refresh token, so the client cannot detect when the user session will expire unless you develop a custom solution.
When coding API calls it is recommended to do this, as in this sample code of mine:
When a 401 is received try a token refresh
On success retry the API call - once only
On failure redirect the user to authenticate again
Out of interest there is an online version of the above app that allows you to test OAuth expiry events to see how this behaves - see my Quick Start page
I am implementing JWT inside a client mobile app with a separate back-end server, and I am looking for an optimum way to use refresh tokens without too much server calls and while keeping a good user experience.
I am new to implementing such a mechanism, and I am confused about many things, so what I am really looking for is a solid conceptual solution to secure the user access to the app, and keep him at the same time logged in indefinitely.
Any correction or suggestion would be most welcome:
Why refresh tokens anyway?
Using a JWT access token alone might compromise the user security: If an attacker holds the access token, he might run feature requests whenever he wants. Even when applying an expiry date to the access token, if the server issues a new access token whenever the old one expires, the attacker will receive this new access token using his old one, and keep accessing the user features.
Refresh tokens stop the attacker once the user regains access to his account using his login/password: When the user uses the app and the server detects that his refresh token is invalid, he will be logged out and a new refresh token and access token are issued after he's logged in with his credentials. The attacker won't be able then to use the old tokens.
My first question would be:
I. Regardless of how the attacker gets hold of the tokens from the user environment, would he be able to use them indefinitely as long as the user is still inactive and isn't logged in again with his credentials to create new tokens?
What about when the tokens are refreshed asynchronously?
Let's imagine a scenario where the user is inside the app, and at least two server calls are run asynchronously:
"Service1" makes a server call with an expired accessToken1 and a refreshToken1, and the server responds by sending a new accessToken2 and refreshToken2
Before receiving the "Service1" response, "Service2" makes an other server call with accessToken1 and refreshToken1, the server compares refreshToken1 to the previously saved refreshToken2 and finds them different. It responds then with an Invalid refresh token response, and this causes the user to be logged out!
To avoid this problem and keep the user logged in, there could be a centralized authentication service that checks first the validity of the tokens before any server call is made. Which means that any call won't be executed unless the authentication service is idle, or wait for the new tokens if it's already loading.
My second question here is:
II. Having such a service to avoid the asynchronous refresh token problem means more round trips to the server, which might prove costly. Is there a better solution?
There are some steps to login / revoke access to an api:
When you do log in, send 2 tokens (Access token, Refresh token) in response to the client.
The access token will have less expiry time and Refresh will have long expiry time.
The client (Front end) will store refresh token in his local storage and access token in cookies.
The client will use an access token for calling APIs. But when it expires, pick the refresh token from local storage and call auth server API to get the new token.
Your auth server will have an API exposed which will accept refresh token and checks for its validity and return a new access token.
Once the refresh token is expired, the User will be logged out.
JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with.
What about when the tokens are refreshed asynchronously?
that supposed be done with a single request to an endpoint, so there is a single accessToken
Having such a service to avoid the asynchronous refresh token problem means more round trips to the server, which might prove costly. Is there a better solution?
i think that's the best & secure solution for mobile and serverless apps, token are like ssh keys must be kept secure all the time :)
for more information check [question]: JWT refresh token flow
Here's the official introduction to JWT
Does VaultSharp manage token life cycle? I am using VaultSharp and see the token lease duration is set at 3,600 seconds. I ran some tests within that time using a singleton instance of the VaultClient object. Everything worked as expected. Only the first API call triggered a call to login and all subsequent calls went through. Once an hour passed, a call to encrypt just threw an exception with a permission denied error. VaultSharp did not make any attempts to renew the lease or authenticate to get a new token behind the scenes. I was previously using VaultAgent and token life cycle was managed via VaultAgent. I was hoping VaultSharp would eliminate the need to use VaultAgent.
VaultSharp doesn't do token lifecycle management, at this point in time.
Vault agent is a client side daemon that runs on its own. VaultSharp is intended to be integrated into an application programmatically.
You are correct on your initial observation. VaultSharp performs the login operation only once. After that the Vault token is used for ever.
At this point, the expectation is for the consumer of the library to record the lease expiration time, and renew the creds accordingly.
If you strongly wish for the lifecycle feature, please create a GH feature request and I'll triage it.
we are looking for some advice on how to use an access token within a long running background process that exceeds the token expiry. We are using Keycloak with OpenId Connect and we would like to stick to the standard. Maybe bend it a little bit, if necessary, but not overthrow it.
Use-Case:
User calls a service with his access token. The service starts a long running background process that calls other services. The access token is being sent to the other services in order to authorize the request and relate the action to the user (e.g. "changed by"). The background process may take days or even weeks.
Any ideas? Thanks in advance!
You need refresh token with offline_access scope. Such refresh token never expires and is used to get new access token when the old one expires.
To get refresh token with offline_access from KeyCloak user needs to have offline_access role and you should add "offline_access" to requested scopes.
More on this: https://stackoverflow.com/a/30638344/1540748
Another option is Client Credentials flow, but than you don't have user data in token.
In order to access resources in Azure AD web applications we retrieve an authorization code using the following workflow:
https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-protocols-oauth-code
Now my questions is, does this retrieved code also have a specific lifetime (like tokens have) or will it never expire? I guess it won't expire but I need to be sure about that.
Yes, the authorization code has a lifetime of 10 minutes I think.
You use it to get the tokens you need and then throw it away.
You'll get refresh tokens so you can use them to get more tokens later.
ADAL.NET for example handles the token refresh for you, assuming you properly implement a token cache.
Reference: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-id-and-access-tokens (scroll all the way down) (it's for the v2.0 endpoint, but codes are similarly short-lived in v1)
Authorization codes (work or school accounts)
10 minutes
Authorization codes are purposely short-lived, and should be immediately redeemed for access tokens and refresh tokens when the tokens are received.