I built a RESTful service with authentication mechanism. The authentication works with OAuth protocol (with the library from oauth.net).
My service is for school management. What I have now is only teachers panel. Now I want to add also students panel, wich its almost the same, but I dont want that students be able to edit things, so authorization is required in this case.
When the teacher wants to login, he sends post request to 'authentcation.php' and if the fields are valid, he get back the authentication token from the OAuth. The students login in 'authentication_students.php'
How can I check if the token have privilege to edit things or not with authorization in OAuth?
Token validation is intentionally uncovered by the OAuth 2.0 specification, so the exact implementation is up to you. The server may either provide a custom endpoint where token validity can be checked by protected resources or issue tokens in a format that the client can directly interpret without consulting the server (see e.g. JWS: json web tokens with signatures).
If you're using a library, you can check which approach it supports.
Issuing the token you should request different scopes (analog to user roles) for teachers and students so you can permit or deny access to protected resources based on scopes of the token granted to the client.
The token would need to include a claim with something like "canEdit" = true/false. In your case the authentication is done from two different pages, so it should not be a big problem to populate this claim?
Let me know if I'm totally off here? Am I missing something?
Related
I am still getting confused in understanding the concepts of authorization and authentication in Google Analytics API.
I created the new project at Google Developers Console and enabled the Google Analytics API. But why they are asking these two things in API & Auth section?
Can Anyone give me any real life example which gives clear cut idea about these two things?
Authentication is the process of identifying yourself. When you log in to a service, you authenticate yourself by using some credentials. This credentials usually are a pair of username and password. If the provided credentials are correct then we can say that you have successfully authenticated yourself. But it doesn't means you can do anything on the system. For example maybe your account has been banned or you don't have permission to access the resource.
Authorization is the process of checking if you have the right to do something. To do this, first you have to authenticate yourself, because without knowing who you are it is not possible for someone to check if you have the right to do something or not.
Just imagine an invite-only party. When you arrive, at the door a big guy asks your name. You will say that you're Akilsree1, so you have authenticated yourself. Then the guy will check if your name is on the list of invited people or not, so he will authorize you to enter the party or maybe he will say that you cannot enter because you're not on the list (you do not have permission).
Edit:
In case of the Google Analytics API things are a little bit trickier.
Basically this is what happening:
When you use their API in your app, the user will be redirected to Google to log in (user authentication).
Then when your app tries to do something in behalf of the user, he/she will be asked by Google to give permission to your app to do so (authorization).
After that your app will receive a token which can be used by the app to authenticate itself when uses the API to do that specific thing (app authentication)
More details you can find here.
Authentication meaning recognizing the subject identity. Like, does it exist in the DB?
Authorization meaning granting access to a resource. Like, can this user/role access X page.
In simple language if you want to understand
Authorization is level of access rights that a user has i.e. the
amount of information which he is authorized to access. Example: The
data that a normal user can see in a system will be quite different
from the data that admin user will be able to view and manipulate.
This difference is achieved by means of authorization.
Authentication simply means the submission of valid tokens(i.e.
username,password in most cases) which are recognized by the system
and by which system will grant access of system to particular user
Google analytics API requires authorization token for every request sent to it. and OAuth2.0 is the protocol used
hope this helps!
Good luck!
I am here with some general discussion very famous and interesting topic "Token Based Authentication".
I need my registered users to login with API. Scenario is quite simple, We want to pass our login details to Server. Server will check the credentials with database. If credentials are proper then Server will create "Session Id" and return back to user (client end). In subsequent requests user just need to pass that "Session Id" to authenticate and access protected data.
Plenty of people suggest about OAuth 2.0 and also some people suggest about Custom Logic. In custom logic they asked to be very sure about security. I read documentation of OAuth and it's good and descriptive. I'm also liking it to use. But wherever I search for OAuth authentication, they are giving example of third party login.
I had installed Php OAuth extension at my side for supporting this feature. In examples they asked to create Request Token first using "getRequestToken" function. Using that Request token they asked to call "getAccessToken" function to get "Access Token". Using that Access Token just need to call "fetch" to get protected data.
Now my questions are,
In my scenario, Do i need Request Token? Is that possible to get Access Token directly
What is OAuth Consumer Key and OAuth Consumer Secret key? Do I need such keys in my application? I believe it's used to allow third party applications only. In my case I'm the resource owner and i'm the consumer.
Do you guys have any example for me to study?
Do you know any well known framework for OAuth for PHP?
Is that need any additional database support except "user" table? For storing OAuth details?
Any additional documents to study for this would be highly appreciated.
I read different Grant Types in OAuth but confused how to use to achieve my approach.
Thanks in advance.
From what I read, you do not need OAuth at all. OAuth is need if there is a third party involved that needs access to your user resources.
As you mentioned, you just need a Login API something like https://myserver.com/signin?user=john.doe#gmail.com&password=12345
After successful login, the server generates a GUID and stores it against the user. You can call it sessionId/cookieId anything you like. Response could be something like '{user:john.doe#gmail.com; sessionId=KJN93EJMQ3WEC9E8RCQJRE8F9E}'
For subsequent calls, the sessionId can be passed in the header.
Server validates the session and lets the user in.
Addtional considerations:
I am assuming your server is HTTPS and hence the user/pwd on the URL are encrypted.
For security you might want to invalidate the sessionId have the sessionId renewed periodically.
Have a logout on which you clear the sessionId against the User.
I think it standard stuff if not the logging in happening via REST.
The requirement that I posted before to login with OAuth2.0.
Usually people assume that OAuth2.0 is only for fetching data by Third Party application from resource center behalf of Resource Owner. That approach is called Authorization Code.
OAuth2.0 has various "Authorization Grant". There are four types,
Authrozation Code
Implicit
Resource Owner Credentials (User Credentials)
Client Credentials
After research, I realize that "Resource Owner Credentials" is best suitable for me. I found one perfect library that helps you to understand background process internally. Here's the GitHub link to download.
Found two major issues here,
When I use my Access Token created by my Mozila in Chrome. Surprisingly, It's allowing me to access my private data from other browser.
I'm unsure but will this approach work same with AJAX type of calls (jQuery tool)
If anyone has idea then please share.
Thanks,
Sanjay
I'm currently building a web application which is an AngularJS frontend that communicates with a RESTful API built using Laravel. I'm making good progress, but finding it hard to get my head around how to handle user authentication.
I've been advised that I should be using OAuth for authentication, and I've decided to use it seen as it could be a learning experience for me as well. The package I'm using to handle this is oauth2-server-laravel.
The basic user story is that users can register their username/password combination for the application, and they then log into the application with that same username and password. They're only authenticated by their username and password, and not by any client secret. After login, they should be given an access token which will be send along with every future request to authenticate them on different API endpoints.
The OAuth2 library has a "password flow" grant type which seems to be what I need, however it also takes client_id and client_secret parameters, which I don't want. The request URI is something like this:
POST https://www.example.com/oauth/access_token?
grant_type=password&
client_id=the_client_id&
client_secret=the_client_secret&
username=the_username&
password=the_password&
scope=scope1,scope2&
state=123456789
But what I want is just:
POST https://www.example.com/oauth/access_token?
grant_type=password&
username=the_username&
password=the_password
How am I meant to provide a client ID and secret of a user that has yet to authenticate?
Is there a different grant I can be using, or is what I want to achieve just not suited for OAuth at all?
Take into account, that client id and client secret aren't parameters that you have to force your end-user to pass. They are static and defined in/for your client app (angular app in this case).
All you need to do is to create a record for your main app in oauth_clients table, and create a scope with full access in oauth_scopes table, and send this values when requesting token.
And that's all in fact.
Also, you may want to consider using implicit grant flow in case of building js-only application, because storing client secret and refresh token in a js app is insecure. Using implicit grant in a final product may look like login window on soundcloud and is more secure as the token is obtained server-side without exposing client secret.
Another way to go, if you still want to use password flow is creating a proxy for refreshing tokens. Proxy can hide your refresh token in encrypted http-only cookie, and your js-app don't ask your api for new token, but the proxy instead. Proxy reads refresh token from encrypted cookie, asks the api for new token and returns it. So the refresh token is never exposed. If you set token ttl for an hour let's say, then stealing a token would be quite "pointless*" in case of a normal application, and stealing refresh token would be "impossible*".
*Of course if someone really want he probably could hack it any way.
And yeah, i know this all looks a bit hacky - modal windows for logging in, proxy etc. But also searching on this topic i couldn't find any better and more elegant way of doing it. I think that's still a lack that all js-apps have to deal with if you want a token based authentication.
You are missing something with the OAuth specification. The client_id and client_secret are really important when asking for an access token when using the password method of OAuth v2. In fact, they are important for every method that gives you an access token. They identify the application or the server that has perform the request.
For example, let's say you have your API, 2 mobile applications and another server that do some tasks with your API. You will create 3 clients with their own client_id and client_secret. If your application has various access levels (they are called scopes in OAuth v2), the client_id corresponding to the other server will be able to call functions of your API that require the scope admin whereas your mobile application will only be able to call functions of your API that require the basic scope if you have defined scopes like this.
If your API grows up in the future, this is really essential. Another example, let's imagine you have given an API key (a pair client_id and client_secret) to one of your friend and he has build a nice mobile app with your API. If one day he starts doing naughty things with your API, you can't stop him very easily. Whereas you could have just removed his key pair if you had followed OAuth v2 principles.
OAuth v2 is not an easy thing to understand, take the time to read specifications and good tutorials before developing your API.
Some useful links :
The official RFC : https://www.rfc-editor.org/rfc/rfc6749
A tutorial on Tutsplus : http://code.tutsplus.com/articles/oauth-20-the-good-the-bad-the-ugly--net-33216
Just to add a bit to plunntic's excellent answer: remember "client" is not related to "user", so when I use a password flow I just define the client_id and client_secret as constants on the AngularJS app to tell the api backend: hey, this is the browser app that is being used to request a token.
So before I start, I'm a bit of an OAuth2 newbie, so still trying to really wrap my head around the various permission scopes and grants.
I've managed to successfully implement an OAuth2 server using the Laravel OAuth2 Server package.
The current site I'm working on will simply dogfood from the API, using the client_credentials grant type. I've managed to get this successfully working and can make API calls with the provided access token.
However, I'm wondering how I can implement an architecture similar to Instagram, Soundcloud, etc, who don't require an access_token for basic endpoints, just a client_id. How do they do this? Is this a custom grant type?
Preferably, I'd only like to start requiring an access token when accessing private resources, such as those for modifying user information, etc. As far as I'm aware, for these I'd need to use the password grant type, which isn't a problem.
OAuth has a few flows such as 2-legged or 3-legged which basically tells the developer how many requests he needs to make to the server to get the resource he wants.
For example, in a 2-legged flow you send a request with your id and secret (first request), you get back an access_token and using that token you can make other request for the resource you want (second request).
Comming back to your Instagram example, you can think at using just client_id as a 1-legged OAuth flow, because you make only one request to server to get the resource you want.
You can use such a flow for less sensitive resources, like a profile photo or user's nickname for example.
The implementation of a 1-legged flow is simple:
- If the user_id is valid and the application doesn't need user approval to access requested resource, go ahead and show the resource.
So implementing a 1-legged flow consists in checking if the client_id is valid and checking if the requested resource needs user permission. That being said, you can use 1-legged for requesting a user profile photo, but you can't use the same flow for requesting the user's private messages.
You can read more about each OAuth Flow in The OAuth Bible.
You have two different resources on your server - a) Resources that need some access checks b) Resources that are publicly accessible.
Actions on resources that need access checks should require that a user has been identified via the OAuth header in the request. In the context of Laravel - this would be a route with the 'before' key specified as Oauth.
Actions that do not need access could glean context about what user is relevant by building your routes to accept an argument that gives you context about the user. Let's say that you have a profile that a user can see without any sort of access. Your API endpoint for a JSON representation of that could be /api/profile/[user_id], where [user_id] is the ID of the user profile you would like to see. For these routes where you do not care about access, you can leave off the oauth before filter in your route declaration.
I am fairly new to REST APIs, and I realize there are quite a few questions already posted. However, perusing these has actually left me more confused on how to handle this.
I have created a REST API using Slim Framework which I am simply using to transfer data. I won't be using user logins or authentication, so I believe to secure this I just need a system that using a public key and a private key, but I am just not sure.
If anyone has insight on the correct / most secure way to do this, or any tutorials / resources that would be great. Any help is appreciated.
You can use SSL to encrypt data in transit.
But SSL is just encryption; server-side ssl does not do authentication of the client, nor authorization. You can think of authorization as answering the question is the caller allowed to do what he is asking?. Authentication establishing the identity of the caller or Authentication is usually a necessary first step for doing authorization. Sometimes you don't need "the whole identity" - you just need to ascertain a particular aspect. For example, an automated washroom gate would not need to know who you were, but only if you were male or female in order to ascertain identity. In the same way, some services don't care who you are; they will allow access if you are calling from a particular network (ip whitelist) or if you carry a special token.
To allow the server to distinguish between authorized and unauthorized calls you have some options:
IP whitelist. If you know the IP address of the app or agent which will call your service, you can specify that in your service implementation. The service can check the IP of incoming requests and reject those that are not on the whitelist. This is sort of "implicit" authorization based on the caller's address.
a secret token, that the app provides in each call. You said you didn't want to do authentication, but this is a form of authentication. You might call it a "bearer token". Anyone who bears this token gets authorization. In your server you'd check the value of the token and reject any calls that don't match the well-known value. This works much like the IP whitelist except the token is explicitly passed, and does not have any relation to the network address.
a token + key pair. This is like a username / password, but it can be used to authenticate the app. Use this to provide the identity of the app itself. Check on the service side as above.
a username / password. To authenticate the user of the app.
You may want to combine these to produce the solution you want. In other words, the client request needs to be from the right I address, and needs to have a token/key for the app, and a username/password for the user, in order to be considered "authorized".