The current OAuth flow is not really practicable for daemon apps

[AlexDelPab]

The Auth Code Flow with PKCE is not intended for daemon applications. Perhaps you could add a client credentials flow or similar for accessing the API v3.

Or you could provide a one-time token with longer validity.

Unfortunately I haven't found anything in the documentation, or have I missed something?

[Wilderbill]

What is a "daemon application"? How does it differ from an application which is just making Etsy API calls. The 1-hour validity of tokens is not a problem. Just keep track of the time and if it is about to expire, renew it. Renewal does not require the complete OAuth process or any human involvement.

[AlexDelPab]

A daemon application is a type of software that runs in the background, often as a service or a headless process, and performs automated tasks without direct human interaction. Examples include:

• A server-side job fetching updates from an API.
• A background service syncing data between systems.
• Scheduled tasks running on a cloud platform.

Daemon applications typically do not have a user interface and often do not involve user login sessions. They operate autonomously based on their configuration.

Why is the Auth Code Flow with PKCE Not Suitable for Daemon Applications?

The Auth Code Flow with PKCE (Proof Key for Code Exchange) is designed for securing applications where a user directly interacts with the application and authorizes it to access resources on their behalf. This flow is tailored for client applications that may not securely store secrets, such as mobile or single-page applications (SPAs). Here’s why it doesn’t fit daemon applications:

1. User Interaction Required:

   • The Auth Code Flow with PKCE requires the user to authenticate and approve access via an authorization server. This involves presenting a login screen or similar action, which daemon applications cannot accommodate because they lack a UI and operate without human involvement.

2. Short Token Lifetimes:

   • Tokens obtained via PKCE typically have short lifetimes (e.g., 1 hour). While these can be refreshed using refresh tokens, the entire flow may become cumbersome for a daemon app that operates independently without human interaction.

3. PKCE’s Design Assumptions:

   • PKCE assumes the existence of a "public client" (e.g., mobile app or browser) that cannot store secrets securely. A daemon application, on the other hand, is typically a confidential client capable of securely storing secrets. PKCE's protections against intercepting the authorization code are unnecessary for daemons.

What is the Correct OAuth Flow for Daemon Applications?

For daemon applications, the Client Credentials Flow is usually the preferred method:

1. No User Interaction:

   • The daemon uses its own credentials (a client ID and secret) to authenticate directly with the authorization server and obtain an access token. This flow does not involve end-user authentication.

2. Long-Term Operation:

   • The daemon can use these credentials to periodically fetch new access tokens without manual involvement, as the credentials are securely stored within the application.

3. Simplified Flow:

   • The Client Credentials Flow eliminates the need for exchanging codes or managing refresh tokens in most cases, making it straightforward and ideal for non-interactive clients.

---

My current workaround involves running the Auth Code Flow in my local environment and extracting the refresh token from the response, which I can then use later to refresh the access token.

In essence, Auth Code Flow with PKCE is built for user-involved workflows, whereas daemon applications need flows designed for autonomous operation, like Client Credentials Flow.

[Wilderbill]

I see. I think you will have to live with human interaction every 90 days or so to renew your fundamental Etsy access token. ChatGPT has a good long explanation of why they will never provide forever tokens.
Can you tell us what your daemon app does.
:-)