Add TokenStore capabilities

torepaulsson commented 3 years ago

Is your feature request related to a problem? Please describe. I'm trying to get custom authentication to work, I've managed to get the login to work, I've got an x-ms-principal but I need to get refresh and access tokens from this authentication so that I can call other services in our backend.

Right now there seems to be support for this in appservice, https://docs.microsoft.com/en-us/azure/app-service/configure-authentication-provider-openid-connect.

I cannot find anywhere that it is possible to enable this tokenstore for static web apps?

Describe the solution you'd like Support the token store setting like app-service does.

Additional context I might have missed some configuration, but I think this feature is not available right now?

mkarmark commented 3 years ago

Currently we don't have token store offered or plans to have it offered in the near future for static web apps. Can you elaborate on how you'd use the refresh and access tokens for us to better understand the need?

torepaulsson commented 3 years ago

Hi @mkarmark, First of all, thanks a lot for Azure Static Web Apps, it is really easy to get started with and fills a lot of standard use cases.

I'm unsure if what I want to achieve is a common use case in other micro-service systems. We have multiple micro-services that perform different set of tasks, some hold information, others perform operations and mutations of data. If we make a simple page where we can integrate some of these micro-service functions, we must handle the signin so as to get a an access token when using the services. Some of these websites might be small, could possibly also be internal pages just developed for a specific team, since it is so easy to create.

My idea was to use the SWA as frontend+backend-signin and handling of the user session, something that has been troublesome if you only have a static web app, then configure the proxies.json to forward requests to other microservices, attaching the x-ms--access-token. For me it feels like this authentication feature in SWA is very powerful, it is otherwise quite tedious to setup manually, and you really want to get it right as to not expose any vulnerabilities.

I will continue and explore the App Service instead, but it would have been nice to have the serverless architecture.

mkarmark commented 3 years ago

It sounds like the piece you want auth for is the microservice functions. If that's the case one way you can continue to use SWA is through our Bring Your Own Function functionality. You can have each of those functions gated with App Service Authentication which does have token store enabled and then use SDKs like MSAL to authenticate with those function apps. Does that sound like a use case that will work?

torepaulsson commented 3 years ago

I'm not familiar that much with MSAL so I'll have to study that more, also read up on App Service. The APIs I need to access are hosted on different platforms. By using the token store and the proxy functionality I was thinking my webpage could access other external APIs with minimal implementation in the backend. I'll see if I can get something up an running! Thanks for the help, hopefully once I read some more I understand exactly what I need to do!

MaartenKoops commented 3 years ago

Hi @mkarmark I have a related question to this topic of @torepaulsson.

I have the following setup:

An Static Web App authenticated against a custom OpenID Connect provider.
A linked (bring your own) function authenticated against the same custom OpenID Connect provider (using the authentication/authorization features from the App service aka EasyAuth).

I see the following behavior:

The SWA authenticates at the IPD using the Authorization Code Flow. The code is exchanged at the IPD token endpoint for ID/Access/Refresh tokens.
When I call the function API from the SWA I see the incoming headers like “X-MS-AUTH-TOKEN” and “X-MS-CLIENT-PRINCIPAL” from the internal authentication gateway being populated on the incoming function API request header.

What I was expecting:

I was also expecting that the tokens from the custom IDP where added to the incoming request headers of the function API. Under “X-MS-TOKEN-idpname-ACCESS-TOKEN”, “X-MS-TOKEN-idpname-REFRESH-TOKEN” etc. But this is not the case.

Other finding what pointed me in the direction:

When I enable the TokenStore on the linked (bring your own) function EasyAuth setup. I navigate to the function directly, authenticate etc. The tokens are populated being populated on the incoming function API request header.
After closing the browser, open a incognito browser to the SWA authenticate etc. Call the function API from the SWA the incoming request headers “X-MS-TOKEN-idpname-ACCESS-TOKEN”, “X-MS-TOKEN-idpname-REFRESH-TOKEN” etc are populated but contain information of authentication request that I did navigating directly to the function API.

Other finding:

The SWA is having his own authorization layer, returning auth tokens. When I have a linked (bring your own) function the audience of the token (aud claim of token) is the function. This looks like the same token the EasyAuth layer of the function is using.
I tried to use the SWA “X-MS-AUTH-TOKEN” token to as Zumo token to call the Easy Auth "/.auth/me" endpoint of the function directly using the token as “X-ZUMO-AUTH” header. But this was not working.

The question I have:

Is it possible to populate the tokens of the custom IDP to the incoming request headers of the "bring your own" function API? (it's only the filling of the headers that needs to be done, the rest will stay the same as-is. The "bring your own" will still be authenticated by the SWA authentication layer).

I have the following use case:

I like to have server-driven authentication using the Authorization Code Flow. I don’t like to have a js lib running on the SWA using the PKCE flow.
I like to use the API function as Backend of Frontend (creating ViewModels etc), that will get information from Backend services on behalf of the user (not under a server2server authentication).

SWA auth setup

MaartenKoops commented 3 years ago

I did not get any response on this. @anthonychu, can you add this as an feature request? I think this will be great added value to the product. This way can have the SWA running server-driven authentication and access the Backend service “on behalf of the user” by sending the access-token from the Bring Your Own function to the Backend. In this case the Function needs to get access to the Access-token using the tokenstore/or internal header value?

Can this be added to the Backlog? Or do you like to set up a teams-call to discuss this feature?

anthonychu commented 3 years ago

Thanks. I think there's enough info here. We'll review internally to see if we can support these scenarios and prioritize. To set expectations, we don't have this in our near-term plans so it's unlikely it'll be supported soon.

yerol commented 3 years ago

I have a SWA and a separate function app. Function app has custom auth configured with openid, token store enabled. I've linked this function app to the SWA as "bring your own". Now trying to authenticate the client SWA through function app auth.

Reading the above responses, does this mean that I can use "bring your own function app" with my static web app but I can't login to the auth provider setup in the function app through the web app?

I would expect when you register your own function app to use in static web app, if the function app has easyauth configured on it, it'd replace existing SWA auth module or hook up to the static web app authentication directly instead.

There is zero documentation regarding this configuration (if at all possible that is)

Azure / static-web-apps