How can I generate a usable (live, authenticated) access token without forcing the client through redirect/authentication?
I'm building an IFTTT channel with node/express/oauth2orize. IFTTT requires that a test user can be generated by the endpoint test/setup. I need to return an access token that can be used for the subsequent tests.
Try running the Authentication Tests first, then copy the access token in one of the responses. Then use that value in your test/setup response.
Related
I'm currently using Firebase cloud functions as my mobile app's backend and I'm using Auth0 as my authentication provider.
My problem is that I've used Postman to send test login requests to my API and I'm able to get a valid JWT. I then deleted the user account through Auth0's user management panel and used Postman to test the login function again to see the type of response I would receive. Instead of receiving any errors, I receive a new valid JWT which allows me to access protected routes even though the user does not exist.
I've tried setting the response cache control to "no-store" and yet I'm able to receive a valid JWT. What could the reason be?
I created a single page application (SPA), which relies on GitHub API v4.
The API requires an access token to access, so I created an input element to ask users to store their access token.
I want to persist the entered token so that users don't re-input the token after reloading or re-visiting the site, without building any backend server.
I tried few things to achieve my purpose:
save the token in localStorage
It is very easy, but there are security concerns to store secret information in the storage, so I rejected this approach.
use GitHub OAuth App to fetch tokens
It is not suitable because it requires to store client secret in my app. Since my app is SPA, the stored secret can be read by any user.
use Auth0 to bypass the authentification
At first, it seemed very easy to get GitHub access token, but it requires a backend proxy server to fetch the token as described here
Is it impossible to persist the token without any backend server?
If so, how to persist the token easily? For now, I came up with the below solutions:
use AWS Lambda to encrypt the token and save it into cookie
When users input the token, the app send the token to a Lambda function, which encrypt the token and response it into cookie. When users back to my app, the app send cookie to the Lambda function and decrypt the token and send it back to the app.
use AWS Lambda as a proxy to communicate with Auth0
As described here, Lambda functions can retrieve the GitHub access token via Auth0.
However, I don't want to do this because I don't want to use two external services just to persist the token.
TL;DR When using google oauth on desktop app, what to save on disk to avoid repeated sign in? Save the google user id? or the token? or an session id?
I'm creating an little desktop app, whitch must authenticate to my REST API server. I'm using google oauth2 for that.
The idea is, that when the desktop app will be authentivated, it generates some data that will be send to my server. The server will store the data with the google user id received from https://www.googleapis.com/userinfo/v2/me.
On the first run of the desktop app, it will open the default browser, with and url for my server and start an local http server. then:
my server will redirect the browser to google (with the clientid, secret, etc.)
user logs in and it will be redirected back to the server with the oauth code
server uses the code to get the token, and then the user profile and stores the token and the profile in db, then redirects the browser to localhost with an paramerer
the desktop app catches the parameter and stores it in an file on the disk
next time the desktop app will start it only reads the file for the parameter to send the generated data with it to my server
my question is: what the parameter should be? the google user id? the oauth token? an generated session id for this desktop app? or something else?
when it will be the google user id, it can conveniently sent the data with the user id and the rest server will just store it in db as is. but I don't think it's safe
when it will be the token, the rest server has to with every request also get the user profile from google with the token. and imho sending the token with every request isn't safe either
generating an session id means to store it with the user and the token on the server and the desktop app will just store it and send it with every request. but I don't know if it's safe to do that
As it's normally the case in software development you have a couple of options depending on requirements.
The mandatory requirement is that your client (desktop) application needs to send something to your REST API so that the API can perform up to two decisions:
Decide who the user is.
Decide if the user is authorized to perform the currently requested action.
The second step may not be applicable if all authenticated users have access to exactly the same set of actions so I'll cover both scenarios.
Also note that, for the first step, sending the Google user ID is not a valid option as that information can be obtained by other parties and does not ensure that the user did authenticate to use your application.
Option 1 - Authentication without fine-grained authorization
Either always sending the id_token or exchanging that token with your custom session identifier both meet the previous requirement, because the id_token contains an audience that clearly indicates the user authenticated to use your application and the session identifier is generated by your application so it can also ensure that. The requests to your API need to use HTTPS, otherwise it will be too easy for the token or session ID to be captured by an attacker.
If you go with the id_token alternative you need to take in consideration that the token will expire; for this, a few options again:
repeat the authentication process another time; if the user still has a session it will indeed be quicker, but you still have to open a browser, local server and repeat the whole steps.
request offline_access when doing the first authentication.
With the last option you should get a refresh token that would allow for your application to have a way to identify the user even after the first id_token expires. I say should, because Google seems to do things a bit different than the specification, for example, the way to obtain the refresh token is by providing access_type=offline instead of the offline_access from OpenID Connect.
Personally, I would go with the session identifier as you'll have more control over lifetime and it may also be simpler.
Option 2 - Authentication + fine-grained authorization
If you need a fine-grained authorization system for your REST API then the best approach would be to authenticate your users with Google, but then have an OAuth 2.0 compliant authorization server that would issue access tokens specific for your API.
For the authorization server implementation, you could either:
Implement it yourself or leverage open source components
⤷ may be time consuming, complex and mitigation of security risks would all fall on you
Use a third-party OAuth 2.0 as a servive authorization provider like Auth0
⤷ easy to get started, depending on amount of usage (the free plan on Auth0 goes up to 7000 users) it will cost you money instead of time
Disclosure: I work at Auth0.
There should be no problem sending the access_token with every request since they are created for that purpose and are thus short lived. You can use the Google Authorization Server endpoint to verify a token instead of using it to do a request for a users profile.
If you're only relying on Google for authentication, here's how your workflow can look:
the client (desktop application, in your case) retrieves the
Google id_token following the user's log in, and then sends it to
the server
the server validates the integrity of said token and extracts the user's profile data; this could mean a simple GET on Google's endpoint to verify this token: https://www.googleapis.com/oauth2/v3/tokeninfo?id_token={0}
On subsequent requests, nothing should change really, except that the user's login process will be automated (since he's given permissions & all), and thus much faster. #danielx is right, there's no problem with sending the token each and every time.
I'm implementing some REST services. All my tests are made using SoapUI.
Recently I decided to adopt JSON Web Token (JWT) for authentication but I could not find any support for this on SoapUI (native install or plugins, nothing).
I found some online generators like http://jwtbuilder.jamiekurtz.com/ but fill all fields, copy/paste on SoapUI again and again for every testcase is not productive at all.
I'm wondering if there is a way to test JWT stuff in SoapUI or if maybe I need another tool. Any advice?
Thanks!
I've found a semi-automatic way to keep a valid JWT token across TestCases without losing too much time, using an external file containing the token.
Have an external tool generating a valid JWT token into a file.
Open your project in SoapUI and add a jwt variable with the value
${=new File('/path/to/token_file.txt').text}
In your requests, reference your variable as a JWT header with the value
${#Project#jwt}
When the token expire, just relaunch the generator script, and SoapUI will automatically load the new token.
SoapUI will call your authentication server and fetch the token, then it will automatically put that token into authorization header (Bearer <token>).
Add new authorization>OAuth 2>Resource owner password credential grant
Then add your username and password into both client and resource section. Finally , put your token end-point as access token url and save the authorization profile to use in other test cases.
I'm trying to get Azure mobile services working with custom authentication. I came across this article:
Get started with custom authentication
and another thread with detailed explanation:
Implement Custom Authentication In Windows Azure Mobile Services.
My question is:
once the token is received after login, does it need to be validated manually similar to this thread ?
I've tried passing the token as Authorization header, but the ServiceUser is always null. (I'm using Fiddler for testing the endpoints)
You do not need to validate the token. Azure Mobile Services will do this for you. For example, it will automatically check if the token has expired, if it has been generated for your particular service (if it's been derived from your Master key), etc.
For example, if you have marked a method with [AuthorizeLevel(AuthorizationLevel.User)] and the token is not valid, AMS will automatically return error response (probably 401 Unauthorized HTTP response). So you do not have to worry about validating the tokens.
In order to use the provided token you have to add the X-ZUMO-AUTH header with the token as value to the request that you send to your service.