# Proper Approach for Programatic Access

**URL:** <https://devforum.okta.com/t/proper-approach-for-programatic-access/5633>\
**Category:** Questions\
**Created:** [July 11, 2019, 4:46pm UTC](https://devforum.okta.com/t/proper-approach-for-programatic-access/5633 "2019-07-11T16:46:38Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![wcarreer](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/wcarreer/32/1240_2.png) [@wcarreer](https://devforum.okta.com/u/wcarreer)\
**Post date:** [July 11, 2019, 4:46pm UTC](https://devforum.okta.com/t/proper-approach-for-programatic-access/5633/1 "2019-07-11T16:46:38Z")

</div>

Scenario:  
We’ve built an application for internal use at my company, the only users will be users on our company domain. There will be 2 types of access: web based access with a traditional Javascript + HTML frontend and programmatic access to our API. This application is completely in python using Flask.

We plan to create an Okta application with a client id and client secret and are using an external library to handle the redirection flow for the planed UI. I have no questions about Web driven UI / authentication flow, it all works as expected.

For the programatic access, I’ve implemented a handler in our code that looks for an "Authorization: Bearer … Okta Access Token JWT … " header, decodes, verifies against the /introspect API in Okta, and finally checks that the client id matches our applications client id.

My main questions are:

1. Is this even “the right way” to allow my users programatic / api access?
2. If its not, what is the recommended way, I’ve been having trouble finding a clear example
3. If it is, what is the proper way to instruct my users on how to obtain their access tokens (via Okta APIs). I currently have a method of doing this calling by /authn then /authorize against Okta but I am extracting the token from the response from authorize, which while it does work, does not seem to be the intended purpose of authorize. I was hoping there was some kind of /token api that my users could call to get their tokens.

---

<div class="post-metadata">

**Author:** ![adrian.lazar](https://avatars.discourse-cdn.com/v4/letter/a/977dab/32.png) [@adrian.lazar](https://devforum.okta.com/u/adrian.lazar)\
**Post date:** [July 16, 2019, 11:25am UTC](https://devforum.okta.com/t/proper-approach-for-programatic-access/5633/2 "2019-07-16T11:25:55Z")

</div>

@wcarreer Hello.

You can leverage the Resource Owner Password Flow (see [here](https://developer.okta.com/docs/guides/implement-password/overview/)). This flow can allow you to do a single POST request to the /token endpoint, where the user’s assigned to the client application can provide their Okta username and password, and will receive in return a Access Token / ID Token.

Please follow the article provided and you should find all the information needed.

---

<div class="post-metadata">

**Author:** ![wcarreer](https://sea1.discourse-cdn.com/oktadev/user_avatar/devforum.okta.com/wcarreer/32/1240_2.png) [@wcarreer](https://devforum.okta.com/u/wcarreer)\
**Post date:** [July 26, 2019, 11:21am UTC](https://devforum.okta.com/t/proper-approach-for-programatic-access/5633/3 "2019-07-26T11:21:16Z")

</div>

For anyone reviewing this later: I examined the Resource Owner flow, but ultimately rejected it on the advice of Okta support engineers. Instead, within our application I allow the user to retrieve their access token to use in Bearer requests via a page they can visit in the App after logging in via Okta. This is a bit more appropriate for our use case, and keeps the entire log in process offloaded to Okta.

---

<div class="post-metadata">

**Author:** ![system](https://global.discourse-cdn.com/oktadev/original/1X/589c4c5f80de422d01f47cee7185a7fb8227835c.png) [@system](https://devforum.okta.com/u/system)\
**Post date:** [January 17, 2024, 11:50pm UTC](https://devforum.okta.com/t/proper-approach-for-programatic-access/5633/4 "2024-01-17T23:50:41Z")

</div>

This topic was automatically closed 24 hours after the last reply. New replies are no longer allowed.
