Till now, the REST API application we've been developing has used a simple api key passed in as a URL parameter, but we've just switched to using the OAuth2 Client Credentials Flow.
This is the simple workflow in which a client POSTs a key and secret via basic authentication and receives an expiring access token. Unfortunately, simple as it is, it's made it considerably more difficult to do quick tests of the API in a browser, either during development or for our support team to do installation sanity checks.
I've tried OAuth 2.0 Playground and REST Console for Chrome, but both of these only seem to support the more complex Authorization Code Grant workflow. Is there a browser-based tool that supports the Client Credentials flow?
Here's my configuration for testing the client credentials flow using the Chrome extension, Postman.
You can actually configure the OAuth 2.0 Playground to use the Client Credentials flow. Just click on the "Wheely" icon on the top right to open the configuration menu and select the "Client Side" Flow.
Another trick you can "Restore" the Playground by generating a URL (click on the "URL" ico on the top right). For instance use this link to have the playground configured for the Client Credential flow automatically: https://developers.google.com/oauthplayground/#step1&response_type=token
Suggest you try Google OAuth 2.0 Playground (https://developers.google.com/oauthplayground/). While it is optimized for Google-specific OAuth2 flows, you can custom configure the OAuth Endpoints and other parameters to use your flow. You'll just need to make sure to use https://developers.google.com/oauthplayground (no trailing slash) for your redirect URI, or you'll get a redirect mismatch (if your system checks that.) Once configured it lets you save a parameterized URL so you don't have to type in all of the configurations the next time you go there.
Currently looking for other tools as well. Happy to post any others I find.
Related
I would like to enable authentication using a REST (preferably POST) call in Apache Shiro. The reason I want to use a REST call is so that both a web and mobile app, as well as a 3rd party using my API can use the same authentication call, which if true would pass back 200 and a token, which would then be used as a query (or form) parameter to authenticate the next call.
Can Shiro support the above described model? I am still evaluating Shiro and learning about it.
I have used some other authentication frameworks but they required that their login page in HTML be used to obtain authentication and I didn't like that because it eliminates mobile and 3rd party use.
For third-party API use cases, you probably want to use an OAuth flow:
Illustrated Guide to OAuth & OIDC
Shiro can act as the "Resource Server", see:
https://developer.okta.com/blog/2020/05/11/java-shiro-oauth
Full disclosure, I work at Okta, and the above link is Okta specific but you could do something similar with another IdP like Keycloak.
I have simple jQuery page that makes calls to azure restful API to get the status of VMs.
I'm facing a problem that it's complaining about Cross-Origin Resource Sharing and I can't find where to set that for the Web app/API I have.
I'm using client credentials grant to get the token
https://learn.microsoft.com/en-us/azure/active-directory/develop/v1-oauth2-client-creds-grant-flow
I have finished my testing and when I tried to do the calls from jQuery/JS I got the CORS problem.
My setup involved:
From Azure portal, I used App registrations to register an app of type "Web app/API", give it a homepage address "this is where it lives", created a key.
Using
POST https://login.microsoftonline.com/<tenant id>/oauth2/token
grant_type=client_credentials
client_id=application id
client_secret=application key
resource=https://management.core.windows.net/
Am I missing any missing anything? my search keeps leading me to Azure hosted apps
Okay, here is how to do it in short:
Add Function App (charge per request)
Open the Newly created function app
In Proxies, select that from the right list
Give it a name, route template will be your new endpoint URL, backend URL is your login endpoint eg: https://login.microsoftonline.com//oauth2/token
After that, back to your function app, select the platform feature tab, Select CORS, delete all of them and enter your application URL or simply a *
You can be more specific with these, but this is enough to get the token. And all the other endpoint didn't have CORS problem.
Good luck.
You cannot use a client secret from front-end Javascript.
Your client secret will be public, it's basically your app's password.
Client credentials grant is for back-end applications.
You need to use e.g. the implicit grant flow with ADAL.JS/MSAL.JS to acquire tokens.
Your front-end app also should be registered as Native since it is a public client.
Here is a sample app: https://github.com/Azure-Samples/active-directory-javascript-singlepageapp-dotnet-webapi
Oh, and the CORS error comes from Azure AD's token endpoint.
You cannot do anything about it.
According to the "tutorial" (the docs themseleves say nothing) Auth0 should set a JWT for me on login, but it's not clear what it means by this. How do I get that JWT?
We already have a login flow in place that uses a hosted page that is accessed through a CNAME CNAME.example.com. Following this process:
I go to example.com/login
I am redirected to the CNAME CNAME.example.com/authorize?...
Then again to CNAME.example.com/login
Username and Password are POSTed to CNAME.example.com/usernamepassword/login
This returns a form containing the JWT and automatically POSTs to CNAME.example.com/login/callback
This then redirects back to our main site example.com/langing-page but the JWT is not received here.
Because it's a CNAME, Auth0 would be able to set an HTTP Only, Secure cookie for our domain, that would be enough.
I've only just jumped on this project and understand that if it was built from scratch we could use the API directly to get the JWT but I can't work out how to do it for the existing flow.
I'm sure we're missing something simple, but the documentation is not forthcoming. Do I need to do a login via the API instead?
EDITED: To clarify the login flow exists and works using a hosted page on auth0, I need to get the JWT after the user has logged in.
MORE INFO: We're using the Auth0 WordPress Plugin which correctly logs us in as the right user (as well as helps us create new users) but does not seem to expose the JWT. That page does mention getting JWTs but refers to the deprecated wp-jwt-auth plugin
The links provided is for general information about JWT's; for accomplishing an authentication through Auth0 there are better suited documentation. In particular, you should start with the quickstarts (https://auth0.com/docs/quickstarts) to check if there's any that is directly associated with the application and stack you're building.
In addition to that, you can also check the docs associated more with protocol flows (assuming you want OIDC/OAuth 2.0): https://auth0.com/docs/api-auth/which-oauth-flow-to-use
The above should guide you about which flow to use and then for each you can follow the links to have a better understanding of how the flow can be implemented.
As an additional note the /login endpoint should be treated as an implementation detail; for OIDC/OAuth 2.0 you need to start the request at /authorize.
I am using an express app and I want to to implement token based authentication I wonder what libraries do I need mainly on both client side and server side? I looked at express-jwt I don't see that library can actually sign the web tokens but I can clearly see that it used for verification so do I need node-jsonwebtoken as well in my package.json? and on the client side I am thinking something like jwt-decode?
If you're looking for a working example using json web token for authentication, you may want to check out this nice tutorial:
http://jasonwatmore.com/post/2015/12/09/MEAN-Stack-User-Registration-and-Login-Example.aspx#views-folder
It explains how to build a JWT-based authentication in a simple way using MEAN stack (NodeJS, Express, Angular, MongoDB). The author uses jsonwebtoken npm package to sign token. This package can also be used to verify tokens.
Im trying to build an OAuth 2 provider and for the web server flow its very strait forward but i cant figure out the best way to implement an installed application flow
most examples ive seen follow essentially the web server flow within an embedded browser in the mobile application, this is also generally how facebook and google demonstrate 3rd party apps to use their APIs
but do facebook and googles own mobile applications actually use that flow or is there some better way to implement mobile authentication
my main problem stems mostly from the client id and client secret, if its embedded in every installed version of a mobile app it becomes essentially useless as it can be easily sniffed, and there's no clear oauth 2 examples of having a per application basis for the client secret
so whats the best way of securing my own mobile app using oauth 2
As you probably want to have user-based authorization and do not want to deal with a username/password on client side, this leaves you the choice to using the Implicit Grant flow or the Authorization Code Grant flow (what you call web server flow).
Now check out the OAuth 2 specification's Installed Applications section. There they state:
When choosing between the implicit grant type and the authorization code grant type, the following should be considered:
Native applications that use the authorization code grant type SHOULD do so without using client credentials, due to the native application's inability to keep client credentials confidential.
When using the implicit grant type flow, a refresh token is not returned, which requires repeating the authorization process once the access token expires.
Whether to use an embedded or an external user-agent is also widely covered by the specification.
For implementing this securely (at least as far as this is technically possible on an open platform), search the specification for the word native and read the sections containing that word multiple times, especially the Client Authentication and Client Impersonation sections.