0

I am creating a .NET class library which will allow local applications to access the accounts of users registered on my website, using an API. I would like the library to handle all authentication of users, so that any app I create an simply call the library, and be returned a token for the API. I'm not sure how to do this authentication.

There are a couple of ways I have considered doing this, however they are not ideal. The first would be to simply create a login form within the library which asks users to enter their login then calls the API. The second method would be to have a webpage where the user logs in and is then given the token which they enter into the app.

The ideal scenario for this situation is that the user does not see their token, and the actual login process is delegated to the website if possible. Both of the above ways lose out on one of those conditions.

The ideal way I would like to do this is inspired from an app I use where if the user is not logged in, they must press a 'Sign In' button, which opens a webpage where they log in. Once they have done so successfully the app automatically detects this and they are signed into the app. The downfall of this solution is that I have no idea how I might do that myself.

Essentially what I'm asking is, is the third solution viable, and how could I do it, or if not are there any better solutions I've overlooked.

FYI the website and API run ASP.NET MVC and WebAPI respectively and the library will use .NET framework.

TobyMeehan
  • 13
  • 3

1 Answers1

0

Edit:

From the comment below it seems likely that you'll want to implement an authentication provider using something like OAuth. The .NET reference libraries can be found here and there's a similar answer already on StackOverflow that may also shed some light.

Welcome to Stack Overflow!

Personally, I would keep the Web API as the authority on authenticating a user and just consume this HTTP endpoint on all platforms (web, desktop, mobile etc) whenever you want to validate a user's credentials.

At a high level the process would be along the lines of:

  • Have your "clients" (desktop, mobile, web applications) submit HTTP requests to an API route (something like /authenticate) when the user first logs in.
  • Run your authentication logic
  • If successful return a token (and cache this this for use in subsequent requests)
  • Otherwise return a 401 response

Every client will now get a standardised response they can use for determining if they should redirect the user to some protected area, or show them an error message.

This also allows you to design login screens that are native to the platform they're running on (which is a smoother user experience). I wouldn't recommend having a library return a pre-built login page to the user - you'll find that becomes a real pain to maintain!

The third solution you proposed is also a valid way of doing things - but it does have the side effect of redirecting the user's focus away from the application they're using - which you may not want depending on your use case. It's also a bit trickier to implement than just calling the API directly, so unless you have a specific requirement to do it this way I'd not recommend it.

Hopefully this makes some sense. If you are unsure on how to implement cross application authentication then I'd recommend taking a look at some existing answers on Stack Overflow such as:

Michael
  • 122
  • 1
  • 2
  • 9
  • In a situation where all my "clients" are built by me this method is ideal. However, I won't be the only person using the API, yet I would still like control over the login process. The best position would be where the app never touches the username and password, and only gets the information it asks for from the API. It seems like this problem is an impossible triangle of requirements so I'll probably have to compromise in some way. Actually authenticating the user should be up to the API, I agree with that. – TobyMeehan Sep 09 '19 at 17:17
  • It sounds like you need to use something like [OAuth](https://oauth.net/) where you can setup an identity provider that consumers have to register with in order to authenticate a user. The client app(s) never see the credentials - it forwards the user on and gets back a token if it was successful. If you Google around [articles like this](https://www.jerriepelser.com/blog/authenticate-oauth-aspnet-core-2/) might give a better overview than I can on how OAuth works (albeit this one is using GitHub as an example). I've updated my answer with some further information. – Michael Sep 09 '19 at 18:51
  • It seems like you're right. The route I'll probably take is something like OAuth, and a setup involving `HttpListener` to get the token to the app. I need to do some more research but you've certainly set me in the right direction so thanks. – TobyMeehan Sep 09 '19 at 19:49
  • No worries! If you're still happy that this answer has sent you in the right direction, please mark it as 'accepted' by clicking the green check mark. This helps keep the focus on older SO which still don't have answers. You can always raise a new question if you have any issues with OAuth etc. – Michael Sep 11 '19 at 21:24