I need to develop an external API, and I want to implement authentication with a client ID and a secret key just like Facebook, Twitter, Google and Microsoft do.
I have read some tutorials about OAuth2, but his generated token is temporary, and clients need to pass the username and password to get a token.
So, what I want is to give a client ID and a secret key to every client that will use my API, and they should pass this data on every method they call. Before returning the result, API checks if the request is valid.
What is the best way to do this?
I think what you're looking for is 'Basic Authentication'. Here's a very simple tutorial to follow in order to fulfill your requirements: http://www.c-sharpcorner.com/blogs/basic-authentication-in-webapi
It goes without saying that you should set your site to force https so that the credentials in request header are encrypted.
Related
I am a student working on a NLP app for the Google Home for my senior design project. I am wondering specifically:
What is the correct way to implement Google Account Linking and what does Google Account linking provide for registering/authenticating users via Dialogflow (i.e. what the dataflow looks like from initial query to Google logging in, back to Dialogflow, then to my ASP.NET Core API handler).
Does Account Linking return a bearer token in the header back to Dialogflow and thus, back to my handler? Or do I have to parse the originalRequest JSON object to get the user information then validate it against the identity provider?
How can I get the user’s information from the Dialogflow request in my webhook (ASP.NET Core API)? Do I have to parse the originalRequest JSON object to get the user info? From my understanding, and from this awesome tutorial, the HttpContext should be populated after verifying the JWT token. What is still unclear, is how to get the token from Dialogflow and Google Account linking.
I appreciate any help or guidance you can provide for implementing user authentication/authorization from Dialogflow to my .NET webhook.
Lots of questions. Let's take them one by one and try to clear up some things.
What is the correct way to implement Google Account Linking [between the Google Assistant and my system]?
First - you need to understand what Account Linking is.
It lets you provide a way for you to authorize a user access to your services. Google uses this to connect a Google Assistant account to an account on your system.
Since this is against your system, the "correct way" depends on your infrastructure. But in general - it means that you'll be issuing OAuth tokens for Google to use and hand back to your webhook. Details for what is expected are in the Actions on Google documentation.
To be clear - you need to be an OAuth server.
What does Google Account linking provide for registering/authenticating users via Dialogflow?
Nothing.
Well, mostly nothing.
All it will do is hand the user off to your OAuth authorization endpoint if it does not already have authorization for that user. It expects you to hand back tokens that it will use.
Does Account Linking return a bearer token in the header back to Dialogflow and thus, back to my handler? Or do I have to parse the originalRequest JSON object...
The auth token (which you have issued, because you're the OAuth server) will be sent in the JSON object at originalRequest.data.user.accessToken.
...to get the user information then validate it against the identity provider?
You are responsible for validating that the access token is one that you issued and is still valid and then... doing whatever you want with it. One assumes that you'll use it to figure out who the user is, however. How you do that (looking it up in a table, passing it to another service, getting the info out of a JWT, etc) is entirely up to you and how you've implemented the OAuth service and what the format of the token is.
How can I get the user's information from the Dialogflow request?
It depends what "user information" you're expecting. By default, Actions on Google and Dialogflow won't give you any information unless you ask for it - and you don't ask for it via Account Linking. You ask for it via using the Actions on Google permission system. But even the permission system won't give you information you may want (most people want email address - which you can't request).
If you want to do it via account linking - you need to request that information when you setup their account.
Do I have to parse the originalRequest JSON object to get the user info?
If you are using permissions, then yes.
If you're not, then while you can parse the JSON to get whatever is sent (the anonymous user ID), it won't just give you information from their Google Assistant account.
Account linking isn't about getting access to their Actions on Google account - it is about getting access to the account in your system when they access your service via the Google Assistant.
HttpContext should be populated after verifying the JWT token
That article talks about using Firebase Authentication as the OAuth server and how to handle it as a client.
Actions on Google turns this around. You need to be the server. It is the client.
It is certainly possible to build a server that uses Firebase Authentication to authenticate users if that is what you wish to do, and to issue JWT tokens as your bearer tokens, but neither of those are requirements.
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'
Currently I am working MVC4.5 with razor,
I have try to integrate Twitter API in My Application but no luck. Could you please help me how to integrate Twitter API in my Application. I have create twitter API which details following
OAuth settings
Access level Read-only About the application permission model
Consumer key - [ConsumerKey]
Consumer secret - [ConsumerSecret]
Request token
URL https://api.twitter.com/oauth/request_token Authorize
URL https://api.twitter.com/oauth/authorize Access token
URL https://api.twitter.com/oauth/access_token Callback
URL http://www.opalevents.org/
Okay, this isn't short and I can't tell you the whole process just with a few lines or even showing some code, but I'll try to give you the directions.
1. Authentication
First of all , most of Twitter API calls need to authentication (using your consumer keys). To authenticate you have to request twitter oAuth TOKENs (that's why request and authorize URL). Without these tokens, you aren't able to make requests for API calls that require authorization.
Authentication is made via oAuth (a lot of plataforms uses oAuth to authenticate, so familiarize with that):
https://dev.twitter.com/docs/auth/using-oauth
You have not specified what you need to integrate, but here explain how you need to authenticate by what you need to integrate:
https://dev.twitter.com/docs/auth/obtaining-access-tokens
if you want to work with user data, you need this authentication: https://dev.twitter.com/docs/auth/implementing-sign-twitter
The basic flow is:
With your consumer keys you request a token to twitter
You'll redirect your application to twitter, to user sign in via twitter
Twitter will throw back to your CALLBACK URL the secret token to make API calls
again, this is a brief, that's all detailed at mentioned docs above
2. Making API calls
Twitter provide a lot of services through their REST API, the documentation is great, and you can find what you need to use easily:
https://dev.twitter.com/docs/api/1.1
Basically each service method have its own url and required parameters for making a call. And when you provide it, you'll receive a (JSON) response.
To help debug, they provide an amazing API explorer, that helps A LOT:
https://dev.twitter.com/console
3. Twitter Libraries
Finally we have some library for twitter written for .NET:
https://dev.twitter.com/docs/twitter-libraries
https://github.com/danielcrenna/tweetsharp
http://linqtotwitter.codeplex.com/
Twitterizer was an amazing library, but seems they have stopped support:
https://github.com/Twitterizer/Twitterizer
some Twitterizer example at Twitter:
https://dev.twitter.com/docs/auth/oauth/single-user-with-examples#csharp
if someone know good ones, please edit this post.
4. Most important
And if you have some question, don't be afraid to research, read , read and read here: https://dev.twitter.com/docs
I need to access the Twitter API user timeline service using the following REST request so I can pull some tweets from a feed to display on a site:
"https://api.twitter.com/1/statuses/user_timeline.json?screen_name=frosario"
It works mostly, but I'm getting sporadic 401 and 500 errors when performing this request; which seem to be because I'm hitting the rate limit for unauthenticated API calls.
I'd like to authenticate with my client Id and secret so I can take advantage of the increased rate limit. I'd like to do this with a server side OAuth flow just using my client id and secret; but could also provide user credentials if needed. However, this needs to be all server side; I can't go through the OAuth redirect flow to authenticate with Twitter's API everytime we load up the site; just to download these tweets. What are my options? I looked over Twitter's OAuth documentation and didn't see anything that would seem to work for my situation; but perhaps I missed something.
Any constructive input is greatly appreciated.
When using oAuth you're using it to authenticate the current user so that you can access their specific tweets and such, which isn't what you're looking to do. You're just looking for a way to download certain tweets right?
You can create a console app or process to download the tweets for you, store them in a database, then read from your database.
If there is a lot of tweets, I'd recommend using the Twitter Stream API.
You just need to authorize your application once.
Check out the MVC quickstart in the Spring Social Twitter extension:
http://www.springframework.net/social-twitter/
I was checking out the Tweet# API, and notice that there are 2 ways to authenticate.
.AuthenticateAs(TWITTER_USERNAME, TWITTER_PASSWORD)
and
.AuthenticateWith(OAUTH_CONSUMER_KEY,
OAUTH_CONSUMER_SECRET,
OAUTH_TOKEN,
OAUTH_TOKEN_SECRET)
if I just want to post as message on a user's behalf, whats the difference?
Thanks
Basic Auth is not secure and going to be deprecated soon. Its sends the user password as plain text (base64 encoded)
OAuth is a (relative?) new method for authentication where no password is needed.
In a few, quick and rough words:
Your app ask Twitter a request token
You redirect the user with the request token to Twitter's login
User logs in and accepts your application
User is redirected back to your app, and a access token is granted for the app.
Any request for consuming user data is made with the access token, so Twitter knows you are one of the good guys.
Keep in mind that OAuth auth is a server-to-server communication.
EDIT:
Official link:
http://oauth.net/documentation/getting-started/
OAuth is way more complex and painful than Basic, but in the end you have a more secure app. Your users will thank you.
The first uses Twitter's basic authentication. It uses an HTTP request, so it's not secure.
The second uses OAuth, more complicated but also more secure.
Both work for updating status (a.k.a posting a message)
More info here: http://apiwiki.twitter.com/Authentication.