# Deprication Admin App

**URL:** <https://community.shopify.dev/t/deprication-admin-app/24740>\
**Category:** Authentication & Access\
**Tags:** access-scopes\
**Created:** [October 31, 2025, 6:50pm UTC](https://community.shopify.dev/t/deprication-admin-app/24740 "2025-10-31T18:50:28Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![AdminGh](https://avatars.discourse-cdn.com/v4/letter/a/3be4f8/32.png) [@AdminGh](https://community.shopify.dev/u/AdminGh)\
**Post date:** [October 31, 2025, 6:50pm UTC](https://community.shopify.dev/t/deprication-admin-app/24740/1 "2025-10-31T18:50:28Z")

</div>

I want to express my concern about this deprication change. I understand the move to dev-dashboard but the fact you cannot create an access token for `machine2machine` integrations is in my opinion completely unacceptable. Most of those `apps` are not apps at all but integrations.

In my opinion this is not improving security at all:

1. You get a wild grown of the basic app templates to get the access token via console.log or db. So you skip the `on time reveal` and have lots of simple db’s just for the token whits the merchants needs to keep save next to the integration party.
2. Because of the hoops merchants will create one token with all scopes and use that for multiple integrations.

It feels like the wrong direction in all regards. An IT department of a big semi-goverement company came with the idea to force users to change there password every 2 months and could not overlap more than 20% and could not been previous passwords. From technical standpoint this sounds great. In practice: sticky note of the new password under each keyboard.

---

<div class="post-metadata">

**Author:** ![TerenceShopify](https://sea1.discourse-cdn.com/shopifycommunity/user_avatar/community.shopify.dev/terenceshopify/32/630_2.png) [@TerenceShopify](https://community.shopify.dev/u/TerenceShopify)\
**Post date:** [October 31, 2025, 7:36pm UTC](https://community.shopify.dev/t/deprication-admin-app/24740/2 "2025-10-31T19:36:44Z")

</div>

We added support for the [OAuth 2 Client Credentials grant](https://shopify.dev/docs/apps/build/authentication-authorization/access-tokens/client-credentials-grant) to support the system-to-system use case you’re describing. It does require an extra API request to acquire access tokens relative to custom apps in the admin, but we feel strongly that this is a net positive change relative to the security risk that unlimited TTL tokens present.

---

<div class="post-metadata">

**Author:** ![AdminGh](https://avatars.discourse-cdn.com/v4/letter/a/3be4f8/32.png) [@AdminGh](https://community.shopify.dev/u/AdminGh)\
**Post date:** [October 31, 2025, 8:06pm UTC](https://community.shopify.dev/t/deprication-admin-app/24740/3 "2025-10-31T20:06:13Z")

</div>

@TerenceShopify I see and this makes thinks a little bit better.

Question: Can we generate multiple valid access tokens after each other and will they all be valid simultaneously? Ideal for stateless apps on for example Cloud Run / Cloud Functions. Aka generate an access token while spinning up and store in memory.

Nevertheless I for see the new `GenerateAccessToken Apps ~ You select the scopes, we provide the token`apps in the app store, would you agree?

---

<div class="post-metadata">

**Author:** ![TerenceShopify](https://sea1.discourse-cdn.com/shopifycommunity/user_avatar/community.shopify.dev/terenceshopify/32/630_2.png) [@TerenceShopify](https://community.shopify.dev/u/TerenceShopify)\
**Post date:** [November 5, 2025, 4:20pm UTC](https://community.shopify.dev/t/deprication-admin-app/24740/4 "2025-11-05T16:20:46Z")

</div>

> [@AdminGh](#):
>
> Question: Can we generate multiple valid access tokens after each other and will they all be valid simultaneously? Ideal for stateless apps on for example Cloud Run / Cloud Functions. Aka generate an access token while spinning up and store in memory.

Yes, you can have multiple active tokens at the same time. Requesting a new token does not invalidate older tokens. Note that within 60s the same token will be issued, although this should work fine for your stateless use case.
