Distribution federation of PKCE

Updated at September 17th, 2024

+ More

Table of Contents

Auth Domain Config Legacy Bolt App Config

We recommend you supply your own PKCE implementation from your own server or auth provider - see this page for more.

However we understand that this may not always be possible given your technical implementations and/or time constraints - this is why we can offer to have distribution supply pre-made PKCE endpoints that can automatically hook into your existing auth packs.

We offer a pre-built auth login screen (and optional register screen) that implements the PKCE OAuth 2.0 flow. You can communicate to users on these pages using our localizable copy and the page can be customized to your needs using theme colours or custom css.

You back-end is patched in behind the PKCE OAuth methods, where you will need to provide login and register API methods from your service and response with an auth token and an optional refresh token. See the page on auth packs for more

Auth Domain

Due to how Firefox browsers open links on Android we MUST use a different domain from the content domain for our distribution-federated PKCE Auth. This is only a requirement when you are using our PKCE sign-in flow that we host and maintain on our server - this is because, by default, the auth and content are hosted on the same domain which is the root cause of the issue.

The domain can be anything, though we recommend something like auth.client-domain.com. This needs to be mapped to pugpig.map.fastly.net in the clients CNAME record in the same way as vanity domains.

Let your onboarder know the domain you have mapped to our Fastly account and we will set-up up in the app for you.

pkce federated distribution

Distribution federation of PKCE

Auth Domain

Related Articles