# Grant non GUI users oauth2 access tokens **URL:** \ **Category:** Questions\ **Created:** [August 22, 2018, 2:08pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520 "2018-08-22T14:08:19Z")\ **Posts on this page:** 12\ **Page:** 1
**Author:** ![derikvlog](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@derikvlog](https://devforum.okta.com/u/derikvlog)\ **Post date:** [August 22, 2018, 2:08pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/1 "2018-08-22T14:08:19Z")
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. ---
**Author:** ![jliu](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jliu](https://devforum.okta.com/u/jliu)\ **Post date:** [August 22, 2018, 2:52pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/2 "2018-08-22T14:52:52Z")
I think a key question is how do you trust and distinguish external clients. With [Client Credential Flow](https://developer.okta.com/authentication-guide/implementing-authentication/client-creds), 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? ---
**Author:** ![derikvlog](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@derikvlog](https://devforum.okta.com/u/derikvlog)\ **Post date:** [August 22, 2018, 3:09pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/3 "2018-08-22T15:09:57Z")
Hi jliu, 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?) Thanks ---
**Author:** ![jliu](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jliu](https://devforum.okta.com/u/jliu)\ **Post date:** [August 22, 2018, 3:49pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/4 "2018-08-22T15:49:32Z")
Hi Derik, 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? ---
**Author:** ![derikvlog](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@derikvlog](https://devforum.okta.com/u/derikvlog)\ **Post date:** [August 22, 2018, 4:33pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/5 "2018-08-22T16:33:38Z")
Hi Jliu, 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:** 1. 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 2. auth/access details pulled from keystore/volt/obtained somehow via code/script 3. rest msg generated with access details placed in header 4. batch process fire message to Comp\_B 03:00:00.200 AM 5. Comp\_B ack response in rest call and fire off some backend processes to do what ever needs to be done. 6. 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? Thanks for the help ---
**Author:** ![jliu](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jliu](https://devforum.okta.com/u/jliu)\ **Post date:** [August 22, 2018, 6:58pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/6 "2018-08-22T18:58:26Z")
Derik, 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: 1. 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. 2. 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. 3. And there are hundreds of companies like Comp\_A using this service of Comp\_B Waiting for your clarifications… ---
**Author:** ![derikvlog](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@derikvlog](https://devforum.okta.com/u/derikvlog)\ **Post date:** [August 23, 2018, 8:08am UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/7 "2018-08-23T08:08:58Z")
Hi Jliu, 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. 1. Yes. This is a single company resource management domain 2. 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. 3. 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. ---
**Author:** ![jliu](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jliu](https://devforum.okta.com/u/jliu)\ **Post date:** [August 23, 2018, 10:03pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/8 "2018-08-23T22:03:19Z")
Hi Derik, 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: 1. 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. 2. 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. ---
**Author:** ![derikvlog](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@derikvlog](https://devforum.okta.com/u/derikvlog)\ **Post date:** [August 24, 2018, 12:10pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/9 "2018-08-24T12:10:11Z")
hi Jliu, 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. thanks for the help ---
**Author:** ![jliu](https://avatars.discourse-cdn.com/v4/letter/j/8baadc/32.png) [@jliu](https://devforum.okta.com/u/jliu)\ **Post date:** [August 24, 2018, 12:30pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/10 "2018-08-24T12:30:36Z")
Hi Derik, You may need to confirm from Okta that there is no limit on the number of OIDC apps for you to create in a single Okta org. ---
**Author:** ![derikvlog](https://avatars.discourse-cdn.com/v4/letter/d/278dde/32.png) [@derikvlog](https://devforum.okta.com/u/derikvlog)\ **Post date:** [August 24, 2018, 12:41pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/11 "2018-08-24T12:41:40Z")
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. ---
**Author:** ![andrea](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/andrea/32/2172_2.png) [@andrea](https://devforum.okta.com/u/andrea)\ **Post date:** [January 12, 2024, 11:00pm UTC](https://devforum.okta.com/t/grant-non-gui-users-oauth2-access-tokens/2520/12 "2024-01-12T23:00:19Z")