I am currently building an authentication server for a game. Basically how I have it planned out is a client will connect to our servers and they will authenticate the client and then issue the client a ticket. As long as the ticket is valid the client is able to join servers. Besides authentication I would like to display user stats and other stuff on their profile. I have not done anything with ASP.NET before but I think that is the right way to go on this. I was wondering if anyone knows where I might get started with communication with an ASP.NET web app. Is that too big of a step since I haven't used ASP.NET before? Should I start with something smaller?
EDIT:
Ok so I have a simple WCF Service now but I am having trouble understanding exactly how to use it. How do I actually use the service I created to exchange data between a console app and a ASP web site? Anyone know of a tutorial that creates a WCF service then actually shows how to implement it into a project?
Another option is to use someone else authentication server. I.e. Facebook, Messenger (Live.com), Google all provide OAuth authentication if you can agree to use their list of users.
Side benefit is that you don't need to worry a bit less about personal information (i.e. child accounts require much more care that you want :) ).
What kind of game? Is it a game played on your website or a client application? If it's a website then all you really need is a Login page. Otherwise, yeah WCF.
Related
I'm developing a system with my classmate, he created a self-hosted API using WPF, while I'm on the mobile part. I already get the data using GetAsync and Post data using Post Async, What I want now is Login Authentication to our system.
Here is the Web API I'm talking about.
What I want is to use this as my API for authentication, But whenever I search for this topic, all of the results are Azure, WCF, ASP.Net.
I know that my friend uses ASP nugget to create API while searching so far on this topic. Theirs always using those 3 and the codes for validation is in the ASP, WCF or Azure.
I also don't get the concept of a token and I guess I don't need it on the self-hosted API.
This is the best example of what I'm talking about:
http://www.c-sharpcorner.com/article/xamarin-android-create-login-with-web-api-using-azure-sql-server-part-one/
http://www.c-sharpcorner.com/article/xamarin-android-create-login-with-web-api-using-azure-sql-server-part-two/
These two set of tutorials are very helpful, but I'm not aiming for this thing. I just want a simple authentication using the API on the picture.
It's just a simple school work, I'm the beginner in mobile development and c#.
Thanks in advance for viewing my POST :)
While your question is waaaaaay to broad for a single answer on Stack Overflow, here are some pointers for you. Don't overthink things and keep it simple.
I think the easiest way to tackle your problem is to issue a token for your mobile app. This can be any type of token if you don't really care about security.
So in your app, you present the user with a username/password dialog. Pressing a login button:
you hit your API sending that username and password
API checks whether username and password is in database or a valid combination
generates a token if OK and sends as response and saves that token in database
then when hitting other urls in your API from mobile app, you need to provide the token as header or query string parameter
This is probably the simplest form of authentication you can do.
I would like to add a password protected page to my WPF modernUI application and could use some help with it.
First of all I don't really have a clue how to handle this stuff correctly in my case.
My application is used on several machines. The protected page should be some kind of admin-page to edit a database that is used by the app.
My idea is, that there is only one Admin-account. But this account can be used from any machine. The admin should be able to change his password. So there must be some kind of encrypted password file on the server which can be accessed from any machine. I don't want to store the password within the application, as this would mean that the admin has to change his password on every machine.
So my question is: What is the best/safest solution for my idea? I'm just looking for hints as I don't have a clue what to search for.
The best Practise nowadays for distributed client applications who share a Database is indeed not to have direct access to the Database.
What you need is a WebService. A web service can be anything. It just has to be hosted somewhere. It can be an ASP.NET application, a WCF Service, or even something not .NET related like a PHP or Java application.
The communication between your application and your WebService depends on what you decide to use. Today a lot of people are using so called REST APIs which use either XML or JSON as data transfer format and use the HTTP protocol.
Its not hard to implement such an API since there are ton of Libs and Solutions out there.
You could use RestSharp for the communication at your client side. Which is straight forward and simple. You could also consume a WCF Service. Which is hosted in IIS somewhere.
However your Problem is nothing special and there are several solutions available. The decision is on your side since it depends on a lot of things such budget, available infrastructe etc.
Your question is quite broad but as far as WPF is concerned you could implement custom authentication and authorization in your application by creating classes that derive from the IIdentity and IPrincipal interfaces and overriding the application thread’s default identity. Please refer to the following blog post for more information an an example.
Custom authorization in WPF: https://blog.magnusmontin.net/2013/03/24/custom-authorization-in-wpf/
The actual credentials should be stored on some remote server that may be accessed through a web service, WCF service or some other kind of API. The details of how to actually get the credentails would be implemented in the AuthenticationService class in the sample code from the above link.
I have a C# Azure Web API backend where data is retrieved from a front-end Ionic Mobile App (which is basically an Angular App)
The authorization of users is done via Ionic's cloud service, so they handle the heavy lifting of registering users via FB, Twitter, basic (username/password).
My question is, when I go to call services from my backend API, how can I make sure someone just doesn't read a hardcoded username/password inside of the internal javascript code to access the backend data?
I know it's pretty far fetched, but is there anyway for the API to know the request is actually coming from the app (Android and iOS) and not just from someone trying to insert data and comments from a web browser that is unauthorized?
Since you're calling the API from JavaScript that is available for end users, you can assume that your JavaScript and all the logic/credentials contained within are accessible to all.
There are fairly secure ways around this, and FB/Twitter and their ilk have implemented it (using OAuth). Essentially, on passing credentials to the API, a token is generated, which is then used for subsequent calls to the API instead of the credentials.
You can avoid people randomly firing off 'unauthorized' requests using nonces which are generated when you render the form, and can be used only once to submit the form in question. You can then time-limit the validity of the nonce on the API end. Unfortunately, it's not foolproof, but this will limit the damage of any sort of 'brute-force' attack that you might get.
Again, with any shared 'secret' (that would guarantee the origin of requests), you have to assume that anyone with enough willpower will be able to extract it from apps, thus any method you implement here will be 100% foolproof. Probably the best you can do is have a shared secret generated for each user on each device.
Short answer: you can't.
Long answer: you can (and must) validate the behaviour of a client but not the client itself.
For example we can take a look on Pokemon Go: after a few hours there were bots able to play, after a couple of weeks Niantic started assuming Machine Learning software engineer and encrypt its API using unknown6 algorithm for stopping the bots, but after a few days of hard working the bots came again online.
You can use all the secure method of this universe (whit an high expense) but if someone (that have good knowledge of software engineering) want emulate your client at the end I will reach his objective
I cant seem to find the relevant resource for learning this. I am trying to achieve a simple login for my C# application where users will be required to authenticate to use the application, and such the users account level would determine what can be accessed inside the app.
Lets say i have a forum and i want my users to authenticate via the application using the forum credentials, is this possible? what should i know about Security and how is this accomplished?
My thoughts would be i should be able to authenticate using some kind of SQL library? though i am new to C# so i might not be on the right track here.
Thanks for your suggestions.
To authenticate with a web site (forum) you need something like OAuth, see this guide for example. The website needs to provide OAuth.
Authenticating with a web site that was not explicitly designed to support an app client is not really possible, at least not correctly.
I'm looking for some guidance on the best way to authenticate to my WebService. Right now, I have a standard WebService on .NET 3.5, and a MVC website that sits on top of this WebService.
The MVC website uses OpenID to authenticate users, and during the development phase, we have simply been passing the user's OpenID Claimed Identifier to the WebService to authenticate. Obviously this is not what we will be releasing to the customer when we go live.
So my question is this: What's the best way to authenticate to the WebService?
Some of the API's I've played around with use Authentication Tokens. Another idea we had was to, upon connection to the WebService, pass the client an encryption key which they could use for all transfers.
I'm thinking out loud here, and again, any help is greatly appreciated! Thanks!
...
UPDATE: Right now I have created a custom SoapAuthenticationHeader which has an OpenIdURL property. This is used on all service calls to authenticate the user. The problem is two-fold:
If a hacker know's a user's OpenIdURL, they can easily gain access to the WebService.
The OpenIdURL is currently passed in plain-text.
So I could pass an encryption key to the client upon connection to the WebService, and have the client encrypt the OpenIdURL in the SoapAuthentication header. But I'm not sure about how to best go about that...
You might want to take a look at OAuth:
http://oauth.net/
(Use http://oauth.net/code/ for coding.)
As it is geared specifically for this scenario (Open ID isn't, really).
There is another question on SA which asks about the best way to secure a web service, and Open ID and OAuth are both discussed:
Web Service Authentication using OpenID
ASMX web services (which Microsoft now considers to be "legacy") have no ability to use OpenID for authentication. They can only use what IIS provides to them. You could possibly add a SoapExtension that would do OpenID authentication for them, but I wouldn't spend time there.
I don't know enough about OpenID to be certain, but I suspect it can integrate with WCF through federated security. I'm sure someone else will answer with details on that.
This isn't really an answer, but I can't leave comments...
You say "I have a standard WebService on .NET 3.5, and a MVC website that sits on top of this WebService".
I might be way off base here, but the language implies that these two sit on the same server. If so, why can't you just share the users database and the cookie token?
James