What I am trying to do ?
I am trying to build api for online booking flight so that other travel agency can use that api. It have function to search the flight, show the search result,book the flight and online payment.So, for the authorization I am planning to use oAuth. When the user visit the travel agency site they can search,book the flight and can do payment .Here, they don't have to authenticate for searching the flight and booking but payment is done by using third party. What I am trying to do is that when user is using the api they don't need authentication but we should authorize that the user is from valid site or not so I am using the oauth grant type client credentials
What I have done ?
I am trying to use the laravel package lucadegasperi/oauth2-server-laravel for the oauth. I had successful install the package on my project and done configuration according to the information provided from here https://github.com/lucadegasperi/oauth2-server-laravel/wiki. I had tested to get access token using the chrome extension postman .
What I am confused about ?
If I share the client_id and client_secret on the client side then any other user can use that client id and client secret and use our api . How can I generate the access token after user submit search button and used that token for the other process like showing search result, booking etc.
So, my question are
Am I using right grant type for authorization ? If not , which will
be the suitable for this?
How can I use client_id and client_secret so that we can authorize
site securely ?
You can write a Wrapper application that will contain your Client_Id, Client_secret. and your wrapper application will manage Access token as well.
Idea is:
Whenever any request will come to your wrapper, then it will look if there is any Access token exist in the cache, if yes, then take that token and make a final request to your application and grab data based on your token.
If Token doesn't exist in Cache then Wrapper app will make a token request based on your Client_id and Client Secret and get a token and store token for next call.
By this way, your application does not expose your credentials & token at publically.
Related
I have started a PHP project (A Project Management Item Tracking Tool) using an API centric approach and have made a fairly good start.
I have created 2 GET the methods so far I want to restrict access but don't know where to start.
In the context of my database
Project is the container that encapsulates different actionitems.
Actionitems are 'assigned' to a user.
Users exist in a database.
Roles as assigned to a user. (User, Admin, Super)
User can only update their own item
Admin had create and update privilege
Super has total administrative privilege
My question is: Where should I start in PHP to only allow
accessing the api via proper users, either via a login api, or some
other means? Any help to get started would get me going.
To start I have successfully created an endpoint to access access resource (actionitems) using a JSON string to test the response.
Existing Endpoints I want to restrict
GET /api/actionitems/
With a general structure to access specific resources within a table as follows:
GET /api/actionitems/4
Note additional api endpoints should be accessed as follows
each route as up to 3 route tokens (following the /api/)
GET /api/users/123/actionitems (get all actionitems for user 123)
GET /api/users/123/actionitems?<more-filers> applies further filtering
You need to handle authentication and authorization for your APIs.
These are very basic steps to understand the solution:
Client calls login API using user credentials(username, password).
Server authenticates user credentials and generates a token.
Server stores this token in database against authenticated user id and responds to client.
Server already has authorization role rights to access different APIs associated with this authenticated user in database.
Client calls resource APIs using token provided by login API.
Server verify token in database and fetch user and user role rights against this token for authorization.
Resource APIs authorize and provides required data or perform actions according to authenticated user role rights.
There are multiple ways to achieve this in standardize way:
3 Common Methods of API Authentication Explained
JSON Web Token
oAuth2.0
You probably want to look at JWT tokens
https://jwt.io/
Here's some quick informations
An API with a token is stateless, you have to send the token on every request , generally in the Authorization Header, the token can contain a payload with some data like the user id the creation and expiration time.
On the server side, when you receive a token with a request you can just find the user id inside the payload and find the corresponding user in the database.
Since the token cannot be modified without the private key you can trust the data you receive.
Then you can just check if the user has some Admin or Super admin roles or if the item belongs to him and send the correct response.
Note: The payload inside the token is public meaning that everyone can read it, don't put any sensive informations.
If you want to use some long term authentication you can use refresh token with jwt tokens, they are stored in the database and can be used to create a new jwt token.
Hope this can help.
I am developing an application from where I would like to create Campaign with list. The application flow is like this, User will click a Button then user will redirected to MailChimp login page, User will come back to my site after Logged in where URL is http://127.0.0.1:8000/home?code=f0f6949c8b5286c38a90aa4820776e14.This code is Authorization Code.
Now I would like to fetch Lists of that specific user who is logged in few moments ago. I can fetch my Lists using API key, but I need users Lists, I don't know users API key.
How can do that ?
I think I need OAuth 2 token of MailChimp API call to fetch User's Lists. How can I get OAuth 2 token of MailChimp API call ?
Thanks
From the MailChimp documentation (source: http://developer.mailchimp.com/documentation/mailchimp/guides/how-to-use-oauth2/)
How to Use OAuth2
For developers integrating platforms that require clients to access MailChimp’s servers, we recommend using OAuth2 for authorization. OAuth2 is a secure option that allows third-party applications to access a server without passing user credentials or API keys.
Before You Start
Here are some things to know before you begin the OAuth2 process.
Our server implements v10 of the OAuth2 specification, and supports Web Server Flow.
On the server side, OAuth2 is pure HTTPS, so we recommend using HTTPS for your redirect_uri.
We don’t expire tokens, so you won’t need to use refresh_token.
Register Your Application
When you’re ready to begin, register your application with MailChimp:
In your MailChimp account, navigate to the Account page.
In the account drop-down menu, click Extras, and choose API Keys.
Under the “Developing an App?” heading, click Register and Manage Your Apps.
Click Register an App.
In the fields provided, input your application’s information and click Create.
When creation is successful, you’ll see an Application created message appear, and more information at the end of your form, including the Client_ID and Client Secret. Do not share the Client_ID and Client Secret.
On this screen, you don’t need to save or change the information. Click Update or Cancel to go back to the Registered Apps page, or close the window.
Endpoints
OAuth2 exposes three specific endpoints, and one for metadata.
authorize_uri
https://login.mailchimp.com/oauth2/authorize
access_token_uri
https://login.mailchimp.com/oauth2/token
redirect_uri
Client-side, made available to the browser in use.
metadata
https://login.mailchimp.com/oauth2/metadata
Note
We support wildcards for the redirect_uri so you can provide
data-center-specific information for proper API calls. Wildcards work
as long as the redirect_uri appears to be a user-registerable domain
under a top level domain. For example, if you enter https://co.uk/ as
a redirect_uri, wildcard support won’t work. If you enter
https://mydomain.co.uk/, wildcard support will work. Domain detection
is based on these criteria.
A redirect_uri will also override the path portion of a URL, as well.
For example, a redirect_uri set to https://test.example.com/oauth.php
means that any URI starting with either test.example.com or
*.test.example.com will work (i.e.: https://test.example.com/somethingelse.php is valid).
Flow
To start your application’s connection to MailChimp, start by sending the user to the authorize_uri.
The user will input their username and password to approve your application. “Remember Me” cookies aren’t permitted here.
After the user authorizes your application, our server will redirect your user back to the redirect_uri, along with a code you can exchange for an access_token. The code is valid for 30 seconds.
Your application should then make an out-of-band request to the access_token_uri using the code our server provided.
Our server returns an access_token, which completes the official OAuth2 flow.
To complete the MailChimp flow, make another RESTful request using an OAuth2 client to the metadata_uri.
Our server will return a datacenter string, API endpoint, and login URL, as described in the following list.
dc:
The data center string, like us1, us2. If your API wrapper is data center aware, use access_token-dc as a standard API key.
api_endpoint:
Use https://{dc}.api.mailchimp.com. If you your API wrapper isn’t datacenter-aware, use this API endpoint and the access_token as your API key.
login_url:
https://login.mailchimp.com
Note
The access_token is used as an API key. Users don’t have access to these keys because they are tied directly to your
application. But, the user can de-authorize your application in
MailChimp, which removes and invalidates the token.
Configuration information
User-Specific configuration
client_id
635959587059
client_secret
0da3e7744949e1406b7b250051ee1a95
redirect_uri
http://192.168.1.8/oauth/complete.php
MailChimp standard OAuth2 configuration
authorize_uri
https://login.mailchimp.com/oauth2/authorize
access_token_uri
https://login.mailchimp.com/oauth2/token
base_uri
https://login.mailchimp.com/oauth2/
MailChimp custom configuration
metadata_uri
https://login.mailchimp.com/oauth2/metadata
I am implementing an api in laravel.
what I want is my api should not be accessible from anywhere except from android/ios app.I googled and came to know that I can make use of API KEY.
But I am not sure is it correct way or not.
Currently using OAuth2 for user authentication.
Please help.
What you want to do is to create a token for each user, save it in the client's device , verify it in each request that the client makes.
So basically you want to:
Make a column for the token in the users table
generate the token when the user registers
make a login route so that the user would login with his email,password and he will getback the token to store in the device
make a middleware that would check for the token in each request ( except for the login )
I wrote an article of the exact same thing you want
https://medium.com/#alhasaniq/how-to-add-token-based-authentication-to-laravel-app-s-to-use-in-api-s-1a0e45f9106#.15e3f9quu
I would like to use Google Plus Sign-In to authenticate my users in an iOS app. I have followed the guide for iOS described on https://developers.google.com/+/features/sign-in. The sign in on client side works perfectly with the Google + Platform. I have not understood how to authenticate the user on server side.
I have seen that the access token on the client can be validated to some extent on https://www.googleapis.com/oauth2/v1/tokeninfo?access_token=XYZ123. Is it safe to authentice a client by validating the access token that the user sent over HTTPS?
Are there better solutions when using the Google+ Sign-In button on the client? As I understand it, Google recommends using the Google+ Sign-In button:
The Google+ Sign-In button is an easy way for users to sign up and sign in to your app. This allows you to know who they are on Google+ and to build a more personalized experience for your app, all without having to create yet another username and password
Short answer: yes. On iOS that's the best method of going about it right now. The important thing is that your verification checks what you want, generally:
The client ID is a client ID from your project.
You only use the user ID from the access token
The token isn't expired
The expiry, and other basic verification, is handled automatically when you called tokeninfo. Just make sure you check the client ID, and use the user ID from the the tokeninfo response to look up the local user.
{
"issued_to": "1234.apps.googleusercontent.com",
"audience": "1234.apps.googleusercontent.com",
"user_id": "104824858261236811362",
"scope": "https://www.googleapis.com/auth/plus.login",
"expires_in": 3584,
"access_type": "online"
}
This is an example of the response. The client ID is the "audience" field here (actually, also issued to), and the user_id is the Google user ID - that's what you should look up in your database to find the matching application user.
On Android and the web there are two other options: retrieve an ID token (basically a cryptographically signed token that directly contains similar information to what you get back from calling tokeninfo with the access token), and retrieving a code (that can be used to exchange for an access token and id token on the server side). Those two aren't currently available on iOS, so passing the access token via HTTPS is the best option currently.
I'm working on an API and considering using OAuth (3-legged approach) for authentication and authorisation.
This is the basic idea:
In order for clients (mobile app or web app), to use this RESTful API the user will have to be logged in using identity providers/servers such as Google, Facebook e.t.c
Essentially 3 parties will be interacting here:
The mobile / web app: The one trying to access my API
The API: The site that contains data for the app to run
The identity server: The site that will allow the user to login in order to access the API
Now, the way that I understand this process (assuming I do). This would be the flow (summarised):
The user will try to access data from the API (consumer);
The consumer finds that the user is not logged in;
The user gets a page (with service provider buttons such as Login with Google);
The user clicks the button, and the service provider returns a login form;
The user logs in;
The service provider returns a page asking for specific permissions;
The user grants permission;
The service provider returns an access token to the user;
The user uses the access token to try the request again to the consumer (API);
The consumer takes the token and verifies it against the service provider;
The consumer grants access to the user.
First
Is this process correct (on a higher level), or have I completely misunderstood the whole thing. If it is not correct: Could you offer some tweaks?
Second
After this whole process. How does the consumer communicate with the user? Will I have to be passing around a token on every request made (between the mobile app and the API)? Or can I just use the user details from the service provider to identify the user?
Third
How exactly does the consumer (API) verifies the token provided by the user against the server? Is this already implemented in OAuth, or will I have to do it myself?
Forth and last
In terms of implementation, what would be the difference between the client (mobile app / web app) and the consumer (API)?
I'm new to this, and I am trying to implement it in PHP (the API). If you have any references to PHP code (sample implementations) or external resources, I'd really appreciate it :-)
I am also new for oauth but I'll try to help.
First you could look here for appropriate libraries which could help.
As for me your oauth flow is correct. A good explanations you can also find here.
Keep in mind that authorization server should return an authorization code which you use for obtaining access token.
So your questions:
1) Follow the second link and there - "Authorization Code".
2) With every request to you API you should send your access token. Something like
http://<your api>?access_token=7f813af1-381d-4dd7-b70b-b6a8399b2c00
3) Just use the libraries from the first link. I hope that they have already implemented this. :)
4)Can't exactly understand what you mean. Your client must be able to obtain access token, store it and send it with requests. Your API server must be able to receive access token from client, and give access to api if the access token is correct.