I am trying to build a ZendFramework2 Rest API and want to implement two-legged OAuth2 authentication.
I have been looking around and can not find any resources to help point me in the right direction with this.
Has anyone done this before or know of a good source I am missing?
In OAuth you can make access tokens client specific by assigning a client_id.
This client_id can be stored in some local storage on the client side and reused on the next user login from that client.
When the user logs in first time from a new client (no client_id in the storage for this user) then a new client_id is created and some 2nd verification step can be added to this part of the authentication process. For example sending an text message to his phone number. You could add an expires_at field to the client table so that you can repeat this process if the client_id has expired.
Related
I have built a Room Booking application in FileMaker that accesses Google Calendar via the Calendar API, authenticated with OAuth2.
Everything works well except I am unsure as to the relationship between the OAuth2 Client token flow and the individual FileMaker/GCal users who will use the system.
At the moment, I am both the owner of the project in the Google Developer Console, and the only beta tester, so naturally the system works with my calendar - I log in once, pass OAuth2 my ClientID and Secret, generate my Code, swap it for the Token and Refresh and I'm off.
However, the whole system at the moment only has one Token and Refresh, held in a single row FileMaker table, thus, when I create a second test user, things still forward to my Calendar.
This is where I am unclear. It sounds obvious, but it's hard to find a clear answer on this.
Should I have it so each user uses the same ClientID and Secret (which I keep secret from them) to generate their own unique set of Tokens?
Or is the single set enough, and I'm misunderstanding some other aspect of the system (and if so, what)?
In short: are the Tokens per Application or per User of the Application?
Answering my own question:
CLIENT'S (= Application) STUFF
Client ID: pertains to the Application, general to all users
Client Secret: pertains to the Application, general to all users
Redirect URI: pertains to the Application, general to all users
USER'S STUFF
Authorisation Code: specific to each user, requires the Client ID and Client Secret, and retrieved as a GET variable from the Redirect URL following user's authentication with the 3rd party service (e.g. http://YourRedirectURI.com?code=abc123)
Refresh Token: specific to each user, requires the Client ID and Authorisation Code
Access Token: specific to each user, requires the Client ID and Refresh Token, and is time limited (typically 1 hour) so a new one needs to be regenerated once it expires
NB Users should not see the Client Secret (or ideally Client ID either). They should be used in the Application's internal logic to generate calls for the users' Code/Token but not seen by them.
OAUTH2 FLOW
So, essentially the OAuth2 'Flow' is as follows:
1) Your Client ID + your Client Secret + their authentication login to the 3rd party service = that specific user's Authentication Code as GET var in Redirect URI
2) Your Client ID + your Client Secret + their Authentication Code = Refresh Token & Access Token
3) Your Client ID + your Client Secret + their Refresh Token = new Access Token
I'm looking to create a game server backend for a game I'm creating. We're currently using Firebase for handling of data and ads, and Firebase has built in authentication. Is it possible to have a user log into our app via Firebase's auth system, then confirm the user's authentication when they connect to the game server to ensure it's who they say they are?
Basically, after someone logs into our firebase, can we use that authentication information for a separate server, and what protocol/method would need to be used (if there's a specific one)
I've figured out the two steps you need to get the information required to auth, one clientside and one serverside. Note: the following examples are for the Java apis, but you can use any of firebase's equivalents.
Clientside: In the Firebase-Auth package, there's the FirebaseUser object. This contains information about their auth state, unique details, etc. There is a method here called getToken(), which will grab your token for the current authentication. Once you have this, you want to send it to the server when you need to auth.
Serverside: On the server, there's a FirebaseAuth object. Once you get the token from the client, you can use verifyIdToken(), which will confirm this is a valid token and give you the details about the user when you get the result. I suggest cross-checking the UUID against one a client sends, to just confirm someone didn't get their hands on a token and send a random ID.
Hope this helps.
I'm looking for a way to create a api token after registration without session
And I also have a question:
Regular site have session to identify the current user
But in api How can I identify the current user if we do not create for him a session?
I'm having trouble with these questions
The main concept is that in login request you send e-mail and password and you get the token.
In all next request you send always this token (so you know which user makes the request) and for this you also send other data (if they are necessary).
Of course you need to make sure this token is somehow unique so you can now exactly which user is making the request.
You can implement it on your own or you can take advantage on some ready components.
In fact in Laravel 5.2 you have TokenGuard built in so you can create simple token authentication out of the box. You can watch this movie on Laracasts for further details.
You can also use some other packages for example JWT Auth
I have set up authentication for my application using the Azure Rest API / OAuth 2 flow, following the steps outlined here:
https://ahmetalpbalkan.com/blog/azure-rest-api-with-oauth2/
I have created an ActiveDirectory application within Azure which is linked to an ActiveDirectory instance.
Inside my own application I have configured it to post to the following Azure OAuth endpoint:
https://login.windows.net/<<MY-AD-TENANT-ID>>/oauth2/authorize?client_id=<<GUID>>&response_type=code
This all works fine. I can authenticate against my ActiveDirectory using emails of the form
someuser#<myDomain>.com
However, I have realised that I can also authenticate using any valid microsoft email address, which obviously means that anyone with a valid microsoft email can get an access token for my application e.g.
randomUser#hotmail.com
Can anyone tell me how I can restrict the authentication to just allow users who are in my Active directory? Users with emails of the form
someuser#<myDomain>.com
I have looked through the documentation but have had no luck so far.
Mechanics of Token Validation
What does that really mean: to validate a token? It boils down to three things, really:
Verify that it is well-formed
Verify that it is coming from the intended authority
Verify that it is meant for the current application
Your problem is that you are not doing the number 3 validation.
You probably are missing something like this in your application where you are validating the token:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = ConfigurationManager.AppSettings["ida:Audience"],
Tenant = ConfigurationManager.AppSettings["ida:Tenant"],
});
Currently I have the same problem and trying to figure out a solution.
That's what I found out:
After authentication you get back a JSON Web Token (see this page https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx). After decoding this, there are several information available. But I am not sure which of those could possibly make sure to only allow login of the specified Active Directory.
#Aram refers to the values audience (aud) and tenant (tid). Unfortunately audience is always set to the app_id given with the request and tenant is always set to the tenant-id of the Azure tenant, although you are using a live.com account, for example.
Finally, I came up with the idea of checking for the existence of oid (»Object identifier (ID) of the user object in Azure AD.«, https://msdn.microsoft.com/en-us/library/azure/dn645542.aspx). I hope that this one will only be set if the user is part of the Active Directory that is issuing the authorization.
As a result, I set my app up to do the following: If in the decoded version of the id_token of the Access token response there is no oid property set – the login-request will be rejected.
Problem is: I can't confirm that my approach works, because I don't have a second Azure AD and can't check if only live/hotmail/... users will not be given a oid, but also users from different ADs. Maybe #bobbyr you could try that out and report?
Thanks to Thomas Ebert's prompt I've figured out a way to solve my problem. I don't know if it will help anyone else, but...
Basically when my app gets the token from Azure, before passing it on to the client, I can decode the JWT and just look at the email field.
In my case if the email address isn't one that belongs to my domain I can just send a 401 unauthorized back to the client.
It feels weird that Azure doesn't offer some way of doing this via config, maybe it does, but noone has answered this for me, and I've read enough of their docs now to want to pull my own eyes out so I never see the word Azure again...
I'm very new in oAuth.
I'm writing a desktop based windows client for Twitter APIs. When I'm using value "oob" for oAuth.CallBackUrl. At the time of authorization, I get a PIN (i.e. 75940xx). please help me finding, how shall I use that PIN in my application code to be able to fetch data from Twitter.
An example would be much appreciated.
The PIN replaces the oauth_verifier string. When exchanging a request token for an access token, use the value of the PIN for the oauth_verifier.
There are 3 main steps in OAuthentication. By the sounds of it you have completed the first two. See below for summary of steps.
Request Token Key and Token Secret
Use Token key to grant application access to data. (if this is successful the user will be provided with a PIN
The PIN is then used to exchange the Token Key and Token Secret for an Access Key and Access Secret. The Access Key/Secret are used to access the users data
For a more detailed OAuthentication flow see this link. I would also recommend reading the OAuth RFC. I hope this has been helpful.