I'm trying to create and app that uses reddit's OAuth flow to authenticate the user and retrieve an access token that will be used by my app for further reddit api calls.
When they consume the api call '/login', the client to be redirected to reddit's OAuth page where they will login and and accept or decline. Then they will be redirected to the OAuth callback URL where NodeJS will fetch the token (or the error) and proceed.
What is the best way I can test this flow and obtain the access token in the tests so I can use it for further testing calls?
The best way is to mock the authorization URL in your tests, just to make sure that the rest of your app works correctly.
If you do need a valid token, for some sort of system testing after that, you have to check if the provider supports other authorization grant types that do not require user interaction. Like for example client_credentials or password grant_type.
Related
I want to use azure AD as authentication.
If user who is in certain organization logged in from SPA, and give access token to backend, then I want to permit access from SPA.
So, I want to check if token passed from SPA is valid or not.
How can I do this?, Or Can I do this?
I want to build backend server with node.js app, and deploy backend app to app service or Azure Container Registry.
I think bearerStrategy would work.
Ref https://github.com/AzureAD/passport-azure-ad
BearerStrategy uses Bearer Token protocol to protect web resource/api.
It works in the following manner: User sends a request to the
protected web api which contains an access_token in either the
authorization header or body. Passport extracts and validates the
access_token, and propagates the claims in access_token to the verify
callback and let the framework finish the remaining authentication
procedure. On successful authentication, passport adds the user
information to req.user and passes it to the next middleware, which is
usually the business logic of the web resource/api. In case of error,
passport sends back an unauthorized response.
In the past, there was an ADAL version for node apps. I don't know if it's still valid or not, but here are useful links:
https://medium.com/#liangjunjiang/verify-and-decode-azure-activity-directory-token-bc72cf7010bc
https://learn.microsoft.com/en-us/azure/active-directory/develop/authentication-flows-app-scenarios
We are struggling about what OAuth flow to use with our app.
We are using Node.JS as our back-end API and Angular as our front-end.
What we want to do is, log in an user, retrieve an access token and use this access token in order to make some API requests (basic POST/GET/PUT/DELETE).
A user (still unknown at this point) lands on a login form OR a register form. He proceeds to the login or the registration.
Once logged he's on his dashboard with an access token, now every time he wants to interact with the API he must use his access token in order to interoperate with the back-end. (which is a classical behavior).
This seems easy, we wanted to use the Implicit Flow but we need a client_id in order to retrieve an access token and the user is still unknown at this point.
We then thought about using the Password Grant flow because our users will have a login/password, but OAuth specs. recommend not to use it except we have no choice.
I know this is a super basic question but what kind of OAuth flow do you recommend with this ? If we have no choice we'll just use the Password Grant but wanted to explore every single solution.
Thanks !
I'm not sure I understand what you mean by:
we wanted to use the Implicit Flow but we need a
client_id in order to retrieve an access token and the user is still
unknown at this point.
If you are using Oauth2.0s implicit flow then your angular app should be registered as a public client with the authorisation server - that process would give you a unique client_id for your angular app. Your angular app can then use the implicit grant and redirect the unknown user to the authorisation server's authorise endpoint passing along in the querystring its client_id along with its redirect_uri and various other things.
The authorise endpoint will prompt the user to register/login to the identity provider and consent to the scopes your Angular app requests.
Once the user logs in (or registers), the authorisation server should then redirect back to your Angular app's registered redirect_uri passing an access_token in the hash-segment of the returned http querystring.
Sorry, I know that I'm not answering directly to your question.
But did you consider using an authentification backend as Auth0 ?
Security is key and OAuth is a complex protocol.
Auth0 give you every thing you need to manage users, use a social identity provider, and integration with Angular.
I have a SPA in React that make calls to an external API like:
GET https://myapi.com/api/items/1 or GET https://myapi.com/api/items/.
In myapi.com server, the routes are secured with oAuth2 using express-jwt and auth0-api-jwt-rsa-validation, son only calls with Header: { Authorization: 'bearer ' + token } respond with a status 200.
If I'll consume these calls from a server side application I could obtain the token from POST https://myapi.auth0.com/oauth/token passing client_id, client_secret, grant_type and audience. But since the application is client-side I think there's a best approach, avoiding to expose client_secret and so on.
I tried the implicit-grant approach but I am dealing with the callback_uri and other confusing stuff.
The main idea is to allow the Application, say https//myapp.com/list to consume the API like GET https://myapi.com/api/items (without users, without passwords).
The points:
how to Authenticate the Application without users
which and where make the call to oAuth2 in my Application? (onEnter the top level route, on componentDidMount?) and
how the token is in the response
Since I asked this question in the Auth0 Community I think could be useful for other to share the answer.
For my usecase, the mos important part is
You reached the right conclusions; the use of the token endpoint either for client credentials grants or resource owner password grant (ROPC) is not recommended for a SPA [...] This means that if you want a SPA to access an API without the notion of a user, then that API needs to be public.
So, in my case I'll make the API public or think in some user/password implementation.
I would like to give the users a possibility to login with some external oauth2 provider (facebook) in my app. The client's part is running on mobile device in a native app.
I am not sure which of the approaches below should I prefer ?
Should the client send the user's access token by facebook with each request ? At each request backend asks facebook to validate the access token. Based on the validation's result, backend performs authorization and return corresponding result to the client.
Should the backend ask facebook to validate the access token only at user logon, then issue its own access token, return the access token back to the client and client will use this access token at making requests to the server to avoid contacting facebook at each request ?
I have read some questions about how to implement the auth with facebook and most of the devs are using B, but I haven't seen any explanation why is it good/bad to use A ?
What I see as benefits of the solutions:
backend doesn't need to care about issuing, refreshing, validating access tokens since this is done only by facebook's authorization servers.
this solution seems to be more effective, since it does not require to connect to facebook at each request.
Security tokens issued by Facebook are signed with a digital signature. The API server only needs access to the public key to validate the signature. There's no need at all to contact Facebook after the user authenticates.
A reason to issue your own tokens after the user signed in with Facebook could be to add claims to the token. But obviously having your own authorization server comes at a cost. It's up to you to weigh the pros and cons.
If you do decide to have your own authorization server, make sure not to write your own! There are open source options like Thinktecture IdentityServer.
I will vote for option B and here is my explanation,
Your API must authorise the request every time with some auth token , which cannot be external provider token, in such case anyone with an access token (eg: other developers) of other provider can access your api, basically there is no auth here.
When your sever issue access token, it's easy to validate and when needed could be revoked easily (eg: on password reset)
While authenticating , your server has fully control over issuing access token , so the validation is made only once and doesn't have to do every time while calling the API.
I am developing a Javascript app + REST API.
I want users to authenticate with the app (and underlying REST API) via an OpenID Connect Provider for SSO purposes.
Using the Implicit flow I can get an ID token (JWT) identifying the user to my javascript app. I was hoping that I could then send this JWT in the Authorize header in requests to my REST API to authenticate the user. However, the problem with this approach is that the 'aud' field of the JWT won't be for the REST API server, it would be for the javascript app.
Does this mean Implicit flow is not suitable for my use case, or am I missing something?
Implicit Flow is designed for untrusted clients (such as JavaScript) to obtain identity and also (optionally) access tokens.
With OpenID Connect your authentication request must contain id_token in the response_type parameter, but it can also include token in the parameter too. See 3.2.2.1 in the spec (http://openid.net/specs/openid-connect-core-1_0.html#ImplicitAuthRequest)
e.g.
GET /authorize?
response_type=id_token%20token
&client_id=s6BhdRkqt3
&redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb
&scope=openid%20profile
&state=af0ifjsldkj
&nonce=n-0S6_WzA2Mj HTTP/1.1
Host: server.example.com
id_token means that you will get back the ID token which you have mentioned. The token means that it will also return you an access token, which is what you would use for accessing your REST api.