I am trying out OpenAM as an OAuth 2.0 provider and would like to find an example of setting up OpenAM for this purpose and a client code in Java.
Can anyone help please?
Thank you
I would stard by reading the offical doc:
AM 7 doc
To test if your oauth2 provider works or not, you dont need a client app, just a shell to test few curl commands (i.e. client credentials flow: get token, introspect token, revoke token)
As for your real tests you can find plenty of ready to use apps on github, almost all vendors have thier own repo with test apps in java, spring, python ...
Okta example wich will work perfectly on openam
Keycloak example apps
Related
When we want to use OAuth with Azure API Management, the documentation states that we need to associate the APIM instance with an OAuth server in the OAuth 2 section of the portal.
But I'm a bit confused about this because when I missed doing that, the validation of a JWT token (Validate JWT policy) works just fine.
It sounds like the association between APIM and an OAuth 2 server is only needed when we want to use OAuth 2 from the developer portal or the developer console.
Am I right?
OAuth server registration is done only for the purpose of including OAuth security definition into exported spec and so that test console on dev portal will render convenient UI to obtain tokens to make runtime calls. It's not required for validate-jwt policy.
What is the correct oauth2 flow for a desktop application? Besides a desktop application I have a SPA Web GUI which does use the Implicit flow. There it does not matters if the client Redirects after 3600s to the IdP to issue a new Access token.
But the desktop application needs to be running 24/7 or could be running 24/7. So it needs to automatically refresh the access token via a refresh_token. But since the implicit flow does not provide refresh tokens it is probably the wrong flow for a desktop app, isn't it?
I guess I need the auth code flow, which does provide a refresh_token. But authentication requests needs a redirect_uri. Let's say I want to use Google as my openid provider. With google it looks like I can't register client credentials with a custom URI scheme (https://developers.google.com/identity/protocols/OpenIDConnect). What does work is to register for example http://localhost:9300, which theoretically could be handled by the app.
A
Whats the correct oauth2 flow for a desktop app to receive a refresh_token?
B
Can I catch the redirect_uri via a custom URI scheme without using the implicit flow (Google IdP)? It is way easier to listen for a custom uri scheme than listening on a local tcp port.
C
This is more a general question. Usually desktop apps are public apps, so I should not include client_secret right? So the only flow which would be left is the implicit flow. But how can I renew access tokens according to specs without bother the desktop user every 3600s?
In my case I could publish the app locally so not public, but how is it for a public app?
A - Authorization Code Grant
B - Not sure here, You can register a Custom URI Scheme
C - Not enough information provided.
Are you using the AppAuth libraries? If so you SHOULD use PKCE and then additional security measures for the refresh token should not be necessary, on the assumption that the client never sends the refresh token with anyone other than the IDP over a secure connection.
Does this help?
A: Yes use the code grant
B: yes use a custom scheme. In your case you should use the reverse of your client ID. e.g. com.googleusercontent.apps.123 is the reverse DNS notation of the client ID. Register your client as "Other" in the Google developer console.
C: Yes, it should not include the client secret. That is why you don't need to send the secret for native clients ("Other") when exchanging the code for a refresh token. Just leave that field blank and it'll work.
As suggested by jwilleke, please use an AppAuth library if it is available for your use case as it'll also handle some of the security issues (PKCE).
For native apps (Desktop), you can follow OAuth 2.0 for Native Apps. But this is still under review and you can refer the latest draft from provided link.
With this flow, you can use authorisation code flow to obtain both access token and a refresh token. Refresh tokens should solve the UX related issue when it comes to extended app usage (24/7 and beyond).
According to this working document, there are strict guidelines on client authentication. Section 8.5 discuss about them. As it says client credentials are not recommended
For this
reason, and those stated in Section 5.3.1 of [RFC6819], it is NOT
RECOMMENDED for authorization servers to require client
authentication of public native apps clients using a shared secret
Also as nvnagr has mentioned in his answer, PKCE [RFC7636] is a must to have for native public clients.
My team writes a monitoring system which we have recently migrated the definitions of our monitoring into a git repo. These definitions are comprised of some json and powershell files. VSCode is an ideal scenario for editing and dealing with git. The problem is while developing the monitoring it is nice to be able to execute it against a test environment. Previously all editing was done through a web interface and we allowed ad hoc execution of the powershell against test machines through an API which is secured with AzureAD and OAuth2.0.
VS Code extensions don't have access to the full electron api and you are restricted from creating a BrowserWindow to handle the usual OAuth redirect flow. Is there a way to work around this limitation and allow a user to auth to our api so that we can make calls to it?
Any ideas or possible workarounds would be awesome.
One thing you can do is to use Server to Server via Client Credentials authentication method. There is node npm library here.
You will need to first register your VS code extension into Azure AD via Azure Portal.
The downside of this method is the credential passed to the Web API won't be user's credential but rather same extension specific credentials. But it would be OK in case you don't need VS code user's identity.
The supported way to get a user token for an application that doesn't have the ability to open a Web Browser to auth is the "OAuth Device Flow". Here is a link to a blog about how to implement it with AAD.
https://joonasw.net/view/device-code-flow
You need to host a localhost webserver inside your extension, when you're doing the auth and then pass localhost:port as the redirect URI for the oauth login flow.
can any one please suggest how do i test oauth2.0 by using Apigee edge management Trace tool or web browser. I do not have access to post man rest client or curl.
kindly help.
You can go to http://apigee.com/console.
Apigee console works as a Oauth 2 client as well.
To make it work against your APIs, you need to sign in. After you sign in to the console, you see a "Create your own API Console" link at the top right corner of the screen.
Once you are done defining the client with client_id, secret, redirect url etc. you can launch your version of apigee console and test Oauth 2.0 compliant APIs.
I have been playing with the new Admin SDK in conjunction with the "upgraded authorisation experience" and wondered if someone has and experience/examples on how to use it. From what I have read, if you upgrade the authorisation experience you shouldn't need to use OAuth 2.0 and get a client ID and secret from the API console.
When you upgrade the authorisation, the API console entry is automatically created so you just have to turn on Admin SDK. Your app should then run simply using your own admin credentials.
Have I misunderstood this and if so, what is the benefit of the new authorisation experience?
I can use the Admin SDK just fine if I create a client ID and secret in the API console but this is using OAuth 2.0 then.
If someone has an example of how to use the admin sdk with OAuth 1.0 i could have a look at it would be much appreciated.
You will still need get your tokens and API key...
Take from the Directory API documentation:
If your application has certain unusual authorization requirements, such as logging in at the same time as requesting data access (hybrid) or domain-wide delegation of authority (2LO), then you cannot currently use OAuth 2.0 tokens. In such cases, you must instead use OAuth 1.0 tokens and an API key. You can find your application's API key in the Google APIs Console, in the Simple API Access section of the API Access pane.
If you are looking for an oAuth2 example with GAS, Arun has a nice example he posted on GitHub, see the SO posting: How to authorize with oauth 2.0 from appscript to Google APIs?
Sorry, I don't have any oAuth1 example to interface with the new APIs.