Enable custom 3rd party authentication providers
Outside of out of the box providers like facebook and google, provide samples and guidance on how to authenticate with others like LinkedIn.
We’re moving this back to the unplanned status, as the started work was not completed, and we don’t have a current ETA.
We’ll update the status again once we have more information. This is still an item we’d like to do at some point.
Whilst you cannot do this with Azure Functions, you can do it with Azure API Management. If you were to put this API gateway in front of your serverless functions then you could use this to delegate the security.
I believe you can add custom OAuth2.0 and OpenID Connect providers through Azure API Management.
A slightly more costly solution but an API gateway is generally a must have anyways.
Erik Ralston commented
Would love to add Okta security to my Azure Functions; otherwise, might have to convert them to an ASP.Net WebAPI and I'd rather not.
I use an Identity Server (ThinkTecture) and could be deployed on any cloud or on-premise....the Identity Server provides end-points to call - OIDC/OAUTH 2 - returns a JWT with scope - identity and resource. Should be able to point to this with simple configuration of URL, ClientID, Secret and redirect URL in Authentication/Authorization settings thru App Service.
Also, having option to let user choose from multiple ID Servers (google, facebook, linkedin...etc) could be very popular too, it is only one that can be configure I suppose?
Andy Booth commented
JWT decoding would be a very welcome addition.
William Noel commented
I'm using B2C to front end my Azure Mobile App from which I issue my own tokens. I have to add claims and other handle refresh directly.
I have no intention of ever having an identity store and the liability that goes with it.
I would like to be able to add Functions over time, but need to be certain that all endpoints are secure. Haven't looked at AF just yet, but seems almost certain it will be useful.
Steffen Gammelgård commented
Sortof agree with this, but simply validating tokens issued by my applications is fairly straight forward in a function, as long as the function has a signing key. -with RSA that should even just be a public key, so not that bad.
What would be really neat would be something like asp.net identity, only with bearer tokens and tablestorage, where i simply supply a few basic settings and configuration of endpoints (change password, password reset, get token, the usual account management stuff that we usually dont need to touch)
Rolling my own isnt really difficult, just tedius and not as easily reusable. (mostly because of the way we deploy to Functions right now, which for me has been writing code directly in the browser)
Steve Lee commented
Adding Auth0 as a provider could enable this but outside of Functions itself so might not offer some options.
Shared Access Signatures (SAS) may provide a basic authenticated/unauthenticated scenario to reduce abuse and traffic generation which would incur charges if the function did the validation itself. This was a big problem with AWS Lama until they fixed it with the API gateway hook.
I'm currently fronting my async functions with a queue and SAS. The SAS model is simple and effective.
AWS finally addressed this for Lamba. They gave you a hook in the pipeline of their API gateway to process an auth token and return into the context session attributes.
Better than nothing but there needs to be native support ODIC (mainly JWT validation and decoding) and OAuth support. Not everyone uses Azure AD as the OAuth server to issue API tokens and token translation for OAuth/ODIC is problematic. There is no STS.
Christopher Anderson commented
Thanks for the feedback, Jeff. Expanding our authentication scenarios is something we'd like to address in the future.