Hi,
I am setting up oauth2 for rest springboot interfaces.
Our clients will be websites(we own it, Oauth sdk clients) as well as external clients calling our rest APIs directly from their systems (no GUI -> scripts and serverside apps).
what is the best way to provide 3rd party clients access tokens without the GUI redirect auth process?
I am able to do password grant, but that require base64[client_id:secret] and thus I can not provide this to our customers, leaving me with a rest endpoint where they auth and I then generate a token for them to use after calling the token service on their behalf. not ideal but work around over https calls.
I would like to get an alternative way for the 3rd party clients to auth without redirect/GUI interface if possible.
I think a key question is how do you trust and distinguish external clients. With Client Credential Flow, a client (internal or external) holds a client credential (client id & secret), and uses the credential to get access tokens from the OIDC server (OKta) without the interactive login process (GUI interface). Is that something that may work for you?
Something like that will work and i am hoping for a solution like that, but the only [client_id,secret] I know of, is the ones that is defined for the application. can users be given a client_id and secret as well and if so how will I go about obtaining those to provide to users? (Or am i missing something fundamental here?)
If you really need to authenticate users w/o the interactive login UI, then Resource Owner Credential Flow would satisfy that. BUT, it requires external clients to know the users’ passwords - not something great since a user’s password should be a secret only known by that user, otherwise, it will be less secure, and what about password change. You can see how big a mess it is.
Do you have to authenticate users from external clients? Is it because the external clients need to impersonate a user when they make requests?
apologies but I get a bit confused with the terminology.
when you say, User, do you mean application or person/organizational unit?
What I need is correct access for the User(person/company) to the Rest api
and a way to extract needed details on the rest call (Principal) to find out more about the [Person/Company] for admin/support/auditing, ex. internal processing and async response later on.
Simple example:
Comp_A have a batch process to send some messages via rest to Comp_B 3AM in the night.
2)batch process pull data from database
auth/access details pulled from keystore/volt/obtained somehow via code/script
rest msg generated with access details placed in header
batch process fire message to Comp_B 03:00:00.200 AM
Comp_B ack response in rest call and fire off some backend processes to do what ever needs to be done.
8AM comp_A user log into Comp_B website and look at results before comp_A team meeting.
Comp_B have 1000’s such clients that need to user this service via automated processes.
Am I missing something simple about oauth2? I suppose this flow happens 10Billion+ times each day.
Which Auth/Access flow or work around would you guys suggest for this use case?
The description is helpful. To clarify, when I use “user” to refer to a human user who can log in using an interactive UI, and I use “client” or “app” to refer to software applications.
I am going to make some assumptions to further understand the problem, correct my assumptions if I am wrong please:
The credentials for all the human users, from across all companies like “Comp_A” in the example, are all managed by a single Okta organization.
This one might be obvious, but I want to confirm - the results from the batch jobs are user-specific, instead of company-specific. That means Alice and Bob, both from Comp_A, send jobs to REST API owned by Comp_B. And Alice and Bob will receive different results that are tailored to each of them in the morning.
And there are hundreds of companies like Comp_A using this service of Comp_B
Okay, I am going to call real entity clients CorpClient so we do not get confused. CorpClient will be a Company that is a client of companyB.
Yes. This is a single company resource management domain
No. it is more that John and Jill will work at the same department and the company have systems that interact with other companies on the department/company’s behalf. We care individuals if they specifically interact with us, else just corporate level.
Yes, automated processes is the default way to source information and provide services for clients, which are all enterprise level clients.
So just standard B2B automated system comms via rest.
If I understood correctly, you need to identify which CorpClient the request is coming from among hundreds of clients. I can think of two options:
Create one unique Okta app for each CorpClient. Each Okta app has a unique pair of client id/secret. Client Credential Flow is used to get an access token for a client. There is a claim in the token for the client id. That’s how you can tell which CorpClient the token represents.
Create just one Okta app, and let all CorpClients use the same client id/secret of that Okta app. And there is an unique Okta user representing each CorpClient. The login flow will be Resource Owner Credential Flow, meaning each CorpClient is given the username/password of the Okta user for that client company. The token will have a claim of the Okta user’s identity. You need to use the user identity to map to the CorpClient’s identity.
Neither option involves interactive login using a UI.
Let’s say you have 1000 corp clients. Option 1 requires creating 1000 Okta apps, and option 2 requires creating 1000 Okta users. The numbers of apps/users to manage are the same, and option 1 is cleaner in theory.
I got resource flow but would like to move to the client credentials flow.
I guess i have a bit of a knowledge gap on what is required to give some other client app access to my client app. will have a look at the documentation again and see if there is maybe a tut or example to quickly get this going.
sure, will check the max clients they allow and work around it.
thanks for the help. I just saw a vid on app clients and am now getting a better understanding how it will work with client credentials.