Develop Reference

Azure AD - Get Client Secret Description from Token

For my project I'll have multiple daemon apps making calls to my API with tokens obtained by Client Secret keys. I need a way to identify which calls are coming from which clients, and I was thinking I could use the Description field that is set when adding a Client Secret Key in Azure AD administration. However I've parsed the token's entire payload, and I don't see it in there.
Is there a way to obtain that description using the token? OR is there another way to go about identifying different api users based on the secret key they're using?

No, you cannot know which key was used.
You need to register them as different client apps in Azure AD to differentiate them.

How can I authenticate a windows user over a REST API call without IIS/WCF?

While developing an on-premise, intranet-only REST API server for my company, I managed to completely confuse myself regarding authentication issues.
I have:
A REST web server implemented in C#, using self-hosted Nancy, running as a Windows Service
A C# client that can query the server, run by a user in our company
I do not have:
Any form of access to our Active Directory and/or domain controller, apart from what any application running under Windows normally has
Any way to influence AD settings or configuration
Active Directory Federation Services (ADFS) (I think. We use Windows 7 and Office 2010, just to give some perspective on the state of the software landscape)
Azure Active Directory (AAD)
I want:
A way for the server to authenticate that a request is made by a user of our company
It is perfectly fine if the client has to sent some additional authentication data with each request, as long as it does not contain the user's password in any form
I do not want to:
Have to set up any additional software (my server must be minimum configuration and maintenance, so the average user can install and run it)
Install / configure / maintain an IIS server (see above)
Use ASP.net (way too big for my needs, plus see above point(s))
Handle user passwords in any way (company policy and common sense)
Impersonate the user (I only need to validate the authenticity of the request)
Implement my own user account database. We already have half a dozen services that need their own username/password combinations, I do not want to add yet another one
I have read articles that show how to use Windows authentication with IIS, or how to use Azure Active Directory (AAD) with Nancy. Other questions here have already informed me how to authenticate username / password combinations against the Active Directory. However, none of these satisfy all of my requirements or have requirements of their own (like AAD/ADFS) that I cannot meet.
It seems that Kerberos/SSPI might be what I want, but it seems very involved and quite complicated to get working with C#. It is possible I will have to go this route, but I could really benefit from some minimal working example (the accepted answer provides a C# implementation/wrapper, including an example project, but I can't seem to be able to make heads or tails of it).
Maybe I am naive, but what I image the solution to be is something along the following lines:
The client queries a service (AD, Domain controller, ...?) for some form of authentication token, using the credentials of the currently logged in user
The token is then sent to the server together with the username, as part of the request that needs to be authenticated
The server extracts the token, and queries the same service (AD, Domain controller, ...) whether the token is authentic, valid and belongs to the user in question
Is this possible at all? Ideally, with some sort of ready made library that I can plug in to my projects (I'm reaching, I know)?

You can do this with stateless authentication and Jwt. Send a username and password to "/ auth" (example) and "/ auth" will search the AD (example) and validate if the user exists, then create a Jwt token with the name of the user on load. When you make a request, you will only send a Jwt token and Nancy validates the token.

Can Firebase handle logins over REST?

The documentation claims:
"The Firebase JavaScript, Java, and Objective-C libraries provide built-in functionality for many login providers, but the REST API works a little differently. ... generate user login tokens with your own server side code."
There appears to be no library for .NET/Xamarin, so I need to use the REST API. But there is no "own server side code" on Firebase.
I'm interpreting this to mean I need a separate service (not Firebase) to host software to provide the registration and authentication endpoints. Do I have that right?

Yes it can! (answering the question in title title)
I just fiddlered (is that a word?) how the javascript SDK talks to firebase servers and it turns out it is quite straightforward.
At the beginning you let your user authenticate with your provider of choice (e.g. facebook). You grab the oauth access token and you POST that (don't forget the "application/json" header) to the following location:
https://www.googleapis.com/identitytoolkit/v3/relyingparty/verifyAssertion?key=<YOUR API KEY>
The post data would like like this:
{
"postBody":"access_token=<OAUTH ACCESS TOKEN>&providerId=<PROVIDER ID>",
"requestUri":"http://localhost",
"returnSecureToken":true
}
The <PROVIDER ID> can be one of the following
facebook.com
google.com
twitter.com
github.com
In return you get a nice json which contains a lot of information, one of which is the "idToken" which acts as the authentication token for making REST requests to firebase. You can set it as the "auth" URL parameter of your request.
I wrote a library to handle this (along with email+password & anonymous logins):
https://github.com/step-up-labs/firebase-authentication-dotnet
And I wrote a blog post about it:
http://blog.bezysoftware.net/firebase-authentication-csharp-library/

Yes and No.
You could create binding projects and use the existing FirebaseUI iOS and Android libraries
Xamarin Binding walk-throughs:
https://developer.xamarin.com/guides/android/advanced_topics/binding-a-java-library/
https://developer.xamarin.com/guides/ios/advanced_topics/binding_objective-c/
Firebase mobile libraries:
https://www.firebase.com/docs/android/
https://www.firebase.com/docs/ios/
Otherwise, yes, you are correct, you would need to provide your own server side authorization system.

The need for a server when using REST is not for the actual authentication (Although you will have to solve this issue too somehow), but for generating the tokens that can be used for the client to authenticate against the Firebase REST API.
From the documentation
To authenticate a user with Custom Login, we must provide each client with a secure JWT that has been generated on a server. There are several helper libraries for generating JWTs given a Firebase app's secret. Our secret can be found under the Secrets tab in our Firebase app's dashboard.
Then you could attache this token to REST requests to be authenticated:
'https://docs-examples.firebaseio.com/rest/saving-data/auth-example.json?auth=SERVER_GENERATED_TOKEN'

Implementing security restful API for social app

I'm developing a social network. I have a RESTful API coded in C# and my front end application on objective C. My architecture is very simple:
Iphone Users (mobile app) < - > RESTful API < - > DATABASE
I want to implement authentication for my service and to make is secure. Also i want to be able to retain something in the phone that tells if it is logged or not and with which account.
I've been reading and i found out that oauth is standard for this. i have a lot of questions that i don't understand. There is suppose to be a previously shared between the resource owner and the server.... who's the resource owner in this case? the user itself? and i imagine the server is the RESTful API. About the security token, is it coded in the mobile app? and in the server?
About the token. does the token retain information about my login? I mean, is the token what tells me what user I am while I use the app? this is what differences two users when they ask for example GetMyFriends ?
and for last, whats an API Key and how do I implement it and use it?
thanks.

This question will require a book volume to provide every possible answer, so I'll try to answer a small bit of questions I can and hopefully that will direct you on the right track.
1) How do I make my client-server connection secure?
Use SSL certificate for the HTTP server that hosts your API.
2) How do I implement my authentication and keep track of which user is currently active in the system?
There are numerous ways to implement your own authentication and I'll only provide a short description. Use two instances of UITextField to get user's username (or e-mail) and password. Send those values to your REST API. To keep track of a currently active User you'll either nee to implement a fairly complex solution using CoreData, where you would create a User entity and have something like an "isActive" boolean value that you'll set to YES once a given user logs in. Keeping it a bit simpler you can just store an NSDictionary representation of your active user's parameters you get from server after authentication.
3) Is oAuth standard for this?
No, do not use oAuth for your own application. You only need to use oAuth to provide third-party applications an ability to log in users into your web application. xAuth is standard - request authentication credentials from user via UI in an application and send those credentials via your API to server and process the response.
4) About the token. does the token retain information about my login? i mean, is the token what tells me what user i am while i use the app? this is what differences two users when they ask for example GetMyFriends ?
Answer #2 should answer how do you know which user sends request. You can retain an information about the currently active user by setting the values you're interested in in the current session, for example - user_id, so you can distinguish which user sends the GetMyFriends request.
I know this doesn't even remotely covers the whole area of what you're asking about, but you need to do a bit better research on this topic.

Providing SSO support for 3rd party systems in our application without another sign in page

We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.

SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.

When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.

Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.