Implementation Advice and what is possible with Auth0

Help
, , ,
1

Hi All,
We use Auth0 to secure mult-tenant SaaS based site, this works well for username and password authentication, no issues there. (This is a .Net Core implementation, using the new OIDC compliant method)

In addition to the above integration with Auth0, we would like to open part of our application up to 3rd party applications in 2 ways (3rd party applications could be any technology):

  1. Web API
    This will form back-end integration and we can secure this by means of an AP key (secret key) passed into all calls.
    Q1 :Is there a better way using Auth0 since we will have a user (account owner user) who can authenticate via username and password? is that overkill? any thoughts on that?

  2. A page/view via an iframe
    Part of the application has a specific user interface that we want to expose via an iFrame, this effectively runs within our own site, but we need the 3rd party application to authenticate their user when the iframe loads.
    Q2: Is this a candidate for Silent Authentication? any thoughts on this?

Q3: Will the 3rd party application need to create a user in our application (and we create additional Auth0 users and they use the auth0 credentials, eg username and password, or does this work differently?)

Thanks for your time.

2

no comments?

3

These sort of questions are not easy to answer because there’s always a lot of details that may influence the implementation and that someone looking from the outside can easily miss because either they were misinterpreted or not present. In particular, your mentions to account owner user and the fact the third-party application would need to create a user are a bit confusing. In general, you should not use a user identity when you really want to represent just an application (in this case read more about client credentials which is also discussed further below).

Having said that, for the first scenario, opening up an API to third-parties, in general, what I’ve seen is that you can either go really simple (API key approach) or more involved (OAuth2). When looking from the perspective of using Auth0 then it would make more sense if you’re looking for the OAuth2 approach which would allow more flexibility but would always be slightly more complex.

For example, with OAuth2 you could decide that the API access initiated from the third-party application would happen either:

  • on behalf of an end-user; the end-user would authenticate and authorize the application to the access your API with their user identity.
  • on behalf of the client application itself (aka client credentials).

For both situations, most of the work would fall into the third-party client application developers that would have to implement the OAuth2 dance either for an end-user based flow or the client credentials flow. From your side you would likely only have to implement some custom authorization policies in case you wanted to conditionally restrict some application from being allowed to request/perform certain operations.

In this case, you would require the use of third-party clients within your Auth0 account so you should check the applicable reference documentation, for example:

For the second scenario, it seems that it’s something really custom to your business needs and I honestly never did something like that. From a very high-level view it seems that the iframe could be seen as an application of its own that would leverage SSO to show user information when a user has already authenticated, however, the mention to the need the 3rd party application to authenticate their user is confusing for me because it seems the third-party application would have a special user.