cancel
Showing results forย 
Search instead forย 
Did you mean:ย 
Data Engineering
Join discussions on data engineering best practices, architectures, and optimization strategies within the Databricks Community. Exchange insights and solutions with fellow data engineers.
cancel
Showing results forย 
Search instead forย 
Did you mean:ย 

Databricks APP OBO User Authorization

Upendra_Dwivedi
Contributor

Hi All,

We are using on-behalf of user authorization method for our app and the x-forwarded-access-token is expiring after sometime and we have to redeploy our app to rectify the issue. I am not sure what is the issue or how we can keep the token alive. There is nothing mentioned in the documentation which i have shared below please have a look and tell me if i need to check anything or correct anything.

Link: OBO user-authorization in databricks apps 
The App Logs:

Upendra_Dwivedi_0-1747911721728.png

 



1 ACCEPTED SOLUTION

Accepted Solutions

jamesl
Databricks Employee
Databricks Employee

Hi @Upendra_Dwivedi , are you still facing this issue?

The x-forwarded-access-token your app receives is the current userโ€™s access token that Databricks forwards in HTTP headers for onโ€‘behalfโ€‘ofโ€‘user access. You should read it from the request on each call and pass it to downstream SDKs/connectors, rather than trying to have it persist.

You donโ€™t need to redeploy the app when tokens change. Redeploys are only required when you enable/disable User authorization or change scopes; in those cases Databricks requires an app restart to apply the new authorization model.

How to fix
Do not cache the token or connection. Read x-forwarded-access-token per request and create a new DBSQL connection for that request; close it after executing the query. This avoids stale JWTs on connection reuse.

Use App authorization for longโ€‘running/background work. For tasks that shouldnโ€™t depend on a user session, call Databricks with the appโ€™s service principal (OAuth client ID/secret injected as env vars), not the userโ€™s token. This eliminates user-token expiry for those paths.

(see other resources/examples at github.com/databricks/app-templates and apps-cookbook.dev/)

If you have further questions please ask, but if this response helps you resolve the issue, then click the "Accept as Solution" button to let us know!

-James

View solution in original post

1 REPLY 1

jamesl
Databricks Employee
Databricks Employee

Hi @Upendra_Dwivedi , are you still facing this issue?

The x-forwarded-access-token your app receives is the current userโ€™s access token that Databricks forwards in HTTP headers for onโ€‘behalfโ€‘ofโ€‘user access. You should read it from the request on each call and pass it to downstream SDKs/connectors, rather than trying to have it persist.

You donโ€™t need to redeploy the app when tokens change. Redeploys are only required when you enable/disable User authorization or change scopes; in those cases Databricks requires an app restart to apply the new authorization model.

How to fix
Do not cache the token or connection. Read x-forwarded-access-token per request and create a new DBSQL connection for that request; close it after executing the query. This avoids stale JWTs on connection reuse.

Use App authorization for longโ€‘running/background work. For tasks that shouldnโ€™t depend on a user session, call Databricks with the appโ€™s service principal (OAuth client ID/secret injected as env vars), not the userโ€™s token. This eliminates user-token expiry for those paths.

(see other resources/examples at github.com/databricks/app-templates and apps-cookbook.dev/)

If you have further questions please ask, but if this response helps you resolve the issue, then click the "Accept as Solution" button to let us know!

-James

Join Us as a Local Community Builder!

Passionate about hosting events and connecting people? Help us grow a vibrant local communityโ€”sign up today to get started!

Sign Up Now