Looking for pure WebAPI project with auth examples

[martinzokov]

I was looking at this SPA example for an app with authentication and the ability to add social login like Google, FB, etc. However, I'm looking for a pure WebAPI example which doesn't have any Razor views and doesn't have the SPA contained in the same project.

Basically just an Auth API that you can call however you like and it would be only REST based. I think something like that would be useful to plenty of people. Does such a boilerplate app exist already?

[scalablecory]

@Pilchie do we have a pure REST API tutorial?

[Pilchie]

@blowdart - any good examples here?

[blowdart]

None. We don't have auth apis that can be called from REST. We only do OIDC because that's the most "correct" way to do it. An API does not do AuthN, only AuthZ

[martinzokov]

@blowdart that's interesting. Maybe there's a gap in my knowledge but why does it matter if the Auth server is returning an HTML view or just a JWT token for example? I think having an API for AuthN gives you more flexibility in how you handle the login flow. Also, I've seen many examples in other languages like Go and Java that do just that - a REST endpoint which returns a token.

[blowdart]

An API for AuthN would mean your application is taking the username and password, and you're responsible for securing that. OIDC does have a username password flow, but it's considered bad practice.

[martinzokov]

@blowdart Could you elaborate why it's considered bad practice (links to articles would be fine)? Also, if your OIDC app is responsible for your login screen and handles the views with Razor, how do you then integrate that into a flow with multiple clients - e.g. a native mobile app and a website? Do you always redirect to your login page and then redirect back to the source? Apologies for all the questions but it sparked my curiosity about what's the best practice way to do that kind of stuff...

[blowdart]

Basically you don't do the login ever. Or rather your webapi does not. It accepts JWTs and returns 401s or 403s as appropriate. The calling program knows how to react and where to get a login token from and off it goes. Mobile Apps can do it, SPA apps can do it, even powershell can do it. So yes, the apps redirect to the identity provider and then send the newly acquired token.

https://oauth.net/2/grant-types/password/ - described as "limited user". And that's true, you can't, for example, do MFA https://developer.okta.com/blog/2018/06/29/what-is-the-oauth2-password-grant - "This is of course the exact problem that OAuth was created to avoid in the first place"

[martinzokov]

@blowdart Thanks for the explanation! I think I may have phrased my questions incorrectly though. I was originally looking for a sample implementation of an identity provider WebAPI. Or I may have misunderstood the intention of the tutorial I referenced in my original post. Essentially, what I'm after is a sample implementation of the API that would grant the JWT token to the client and other apps would also be able to verify JWTs against that same API.

[blowdart]

Oh!

Well that depends on your identity provider. Identity Server has their docs, AAD has theirs

[martinzokov]

@blowdart Thanks for pointing me in the right direction and explaining the things above!