locked
Web API: Why is it necessary to expose the client secret ? RRS feed

  • Question

  • User-1078583883 posted

    I'm confused about authentication flows.

    I added Swashbuckle/Swagger to my Web Api, not realizing that my client secret would be exposed. The Swagger developers seem to regard it as unavoidable, per this link
    https://github.com/swagger-api/swagger-ui/issues/4448

    Why unavoidable? Doesn't MSAL provide authentication without exposing a client secret? If so, why can't Swagger do it? Or why can't Swagger use MSAL?

    My api is at, say,
    myApi.azureWebsites.net
    and my swagger at:
    myApi.azureWebsites.net/swagger
    How is this usually solved? Is there a tutorial on how to make a separate Swagger UI-app, say at
    mySwagger.azureWebsites.net
    which could forward any request to the backend Api, using httpClient?

    Wednesday, October 7, 2020 2:08 AM

All replies

  • User475983607 posted

    Simply, the secret identifies the client application registered with the identity server.  Your client application is JavaScript running in the browsers.  If this is a problem then make the HTTP requests for the sever not the client.

    Wednesday, October 7, 2020 11:46 AM
  • User-1078583883 posted

    Thanks, but I'm a bit slow. MSAL.js uses the clientID to identify the app, no need for client secret. Why can't Swagger do the same? What is different about the Swagger scenario that I'm missing here? 

    Here's my understanding of MSAL.js.   It redirects to the Active directory URL-plus-clientID  where Active D  shows a login page. The user signs in and gets a token if he is in the same Tenant as that clientID (otherwise denied). Active D redirects user back to my home page URL-plus-token. MSAL.Js extracts the token from the URL. 

    I just don't understand why Swagger can't do the same thing. 

    Wednesday, October 7, 2020 4:37 PM