I'm currently tyring to build an API driven symfony2 web applicaiton.Just a basic application to learn symfony2 and REST.
It would be based on a RESTful api. Calls to the API will be authenticated using OAuth.
For e.g.:
if a client application wants to get data (information about all the fruits) through API it will need to make a GET request to the url and pass the access token as a parameter.So the url will look something like this.
http://www.mysite.com/api/fruits.json?=<access token>
Now the problem is that i would be needing the same data in one of my actions as well.
I need some help here.In order to get get data from above url in one of my actions i will also need to send an access token in the url.
How do i get this access token??
Should there be a fixed token which will be used for all such calls within my application??
You basic application project will grow manifold if you try to do what you want here.
Basically, you need to implement an Authentication Server for this.
i) First, the app should be registered for a scope;
ii) Using the app the user logs in to the authentication/authorization server.
iii) The server verifies if the app has access to the scope and if the user is registered in your system.
iv) Server creates an access token (which is a HMAC signed string) and returns to your app.
v) The app then hits the endpoint (restful API) with the token.
vi) The RESTful service then internally sends the token to the server and fetches the customerID for which the call is made and performs the actions that it's supposed to.
I wrote an answer once on how to create a OAuth Service/Provider - How would an efficient OAuth2.0 server / provider work?
Also, OAuth was designed such that client apps/3rd party software can access a user's resources on his behalf. A very simple example is = An app posting something on your facebook wall on your behalf. It is actually accessing a resource that you own (the wall) and posting to it. You do not need OAuth just to get some data - there are other ways to secure the API.
Related
We're trying to integrate with an external third-party REST-API that's secured with oAuth2 but the service isn't really an identity provider, so I'm not sure what terminology I'm looking for. Obviously when it comes to looking at "asp.net core" and "oauth", millions of hits come up related to adding it as an identity provider but I don't think that's what we want.
This is how I would expect it to work, based on what I've seen in other saas apps:
User logs into the site
User looks at some "third-party integrations" page and clicks to add this one
User's browser is directed to the other service to login
On successful login, user is directed back and we have access to the bearer + refresh token which we store(?) and use.
Some use of this API is in response to user action (refresh to get results), but some is also just background work so I assume we're storing this information and using implicit flow to refresh the token for as long as we can unless it's revoked.
What asp.net core terminology am I looking for, how would someone properly describe this flow in oAuth terms? We're getting confused between authorization, authentication, providers, handlers, middleware, etc.
In terms of this third-party API oauth flow, in case people want to know, here's what's required:
We call a specific endpoint that tells us the correct authorization and token endpoints
We then redirect to the authorization endpoint, which presents the user with the remote service's login page.
The user logs into the other service and is redirected back and the code and grant_type=authorization_code are provided via the url
We call the token endpoint with that information to get the final bearer+refresh token
I have a web site written in Angular that uses a REST api in order to provide functionality.
I would like to know the proper workflow for authentication to the website.
Let's go back to 1999 - I write a website and all the logic is in the web code. There is no REST API. If someone wants to log in to the website they enter their email and password and I store a cookie on their machine and they now have a 'logged-in' session on my website. By having this cookie they are authorized to do certain things such as write a comment.
All good.
Fast-forward to my new website. This website is written in Angular and all content is provided via a REST API. Some of the REST calls just display data like a bunch of comments. Any anonymous user can make these calls just by browsing the page. However, there the user can log in to the website using their email and password. Again, I store a cookie on the user's machine and they are logged in to the website. Now, because they are logged in to the website they can post comments. These posts are done via a REST API call. However, Google and the Interweb have told me that my REST API should be stateless and i should be using oauth2 for this request.
My question is, what is the workflow for this very common auth pattern?
I thought maybe something like:
User logs in with username and password
One request is sent to my web auth server and a session cookie is created
A second request is sent to my api auth server which issues a valid token for further requests
The two systems are quite separate and do not depend on each other.
If i was to add social login to the mix then (2) above would just be authentication to the required social auth server and (3) would be unchanged.
Yes, your REST API should be stateless.
This is a typical workflow for authentication for a REST API.
User logs in with username and password.
A JSON web token is issued upon login from the backend and sent to the browser.
The JWT(JSON web token) can be stored in a cookie in the Web Storage(local/Session Storage) on the browser.
Subsequent requests to the REST API will have the token embedded in the header or query string for authorization. With that form of authorization, your REST API understands who is making the request and what kind of resource to return based on the level of authorization
A practical example of this can be found in this blog post. Angular 2 was used for the sample app implementation.
I hope this helps!
I am building a RESTful API application with Symfony2.
The app will consist of two parts.
JavaScript front-end - everything the user will ever be able to see and do will reside here.
Symfony2 back-end API - every resource and data the user will be able to reach from front-end will be served in standard JSON via endpoints.
I have never built a fully RESTful application before. My main concern is how to authenticate users.
I imagine REST authentication like this:
A user enters his credentials in a form generated in the front end, then the request is sent to the server where authentication logic happens and if the user is authenticated, a response with "token" is sent back to user, that he will add that token to every request url or authorization header (I don't know which of these options is preferable).
Then with every request, the server will check if the user token is valid and if the user is authorized to access that data (roles) and if so serves request data. (I don't want to allow users login with Google, Facebook or anything like that. I want my users logging in to other application using my app)
Now this seems quite simple, but then there's OAuth2 that got me confused because I jumped into developing without research. I downloaded FOSOAuthServerBundle and started messing around when I started to get a feeling that something is not right.
What I would like to know is the difference between RESTful authentication and OAuth.
What are the recommendations for implementing the described login mechanism?
You've got it pretty spot on. You use OAuth just for the authentication and all the following requests will have to provide that HTTP-Authorization header. You would need to create your custom authentication provider to handle that. Also use something like FOSRestBundle to create your resources.
First, let me describe the application: we are working on a web-based software which is some kind of custom help desk application. It requires the user to login (we use FOSUserBundle). After login the user is redirected to the dashboard. From the dashboard there is no more page reload, the frontend is build on Angularjs and the user can get anywhere within the application without page reload. You could speak of a single page application.
So the data that is presented to the user, is fetched from a rest api (we use FOSRestBundle). This works quite well at this point.
There is some kind of dilemma. Only our staff will access this application (for now). So a staff member needs to login to access the helpdesk. The data that is pushed to the frontend via angularjs is called via api, so the user that has just logged in needs to authenticate again on every request because of rest.
Problem: Since the backend runs on symfony2 let us just try to get the user object of the currently logged in user when an api call is made:
$this->get('security.context')->getToken()->getUser()
returns anon. that stands for anonymous, or
$this->getUser();
returns just null.
So the authenticated context seems to be gone when using the rest api. However when I call an action directly without rest, I can get user information.
So what we need is to secure our rest api and get user information on every api call. We don't want third party people to access our application, just staff. I am not familar with OAuth, but the user will be redirected to a third party page to Allow/Deny access to his data? This would not be an option for us.
Based on that information, do you have any suggestions or ideas how to secure the api and transport the user data so that getUser does not return null or anon. but the actuall logged in user?
there's another way to resolve your problem.
It's by using Certificates.
you can generate certificates then use Http tunneling (https obviousley), the server will ask for a certificate (you've to configure Apache for that but it's not a big challenge).
with this in place, you've to add a CertificateManageron the server side to ensure that the certificate is valid and to know who's calling the service (to be able to authenticate the user at each request), the CertificateManager(or what ever you'll call it) will probably have to be configured within you filters chaine (as known in the java world), et voilà
Hop that help you,
Abderrazak
REST is stateless so you will have to send some kind of authentication/authorization in each request. You can use HTTP BASIC AUTH or something like OAuth.
Have a look at https://github.com/FriendsOfSymfony/FOSOAuthServerBundle
I'm kind of building our application in exactly the same architecture (RESTful API with Symfony2 back-end and AngularJS frontend.
Another way is to duplicate the api routes, so that you have the api routes protected by OAUTH and the api routes protected by the session, both of them pointing to the same controllers. The method was explained here: https://stackoverflow.com/a/22964736/435026
I am creating a solution that will contains a website and mobile apps. I will use Zend-Framework 2 for the website.
So, to make it good, I am wondering if it would be a good idea to build :
A REST web service (using zf2)
Another website that will call the REST ws (using zf2)
The mobile apps that will call the REST ws
I will use OAuth for the autentication and security.
My question is, if my website gets the data by calling the REST ws, it will have to make a database request at each call to check the token whereas if I do a "normal" website, my app will be able to use session to store the information of the connected user.
Because, for what I have read, there is no such thing as session with OAuth/REST so for each call, I have one more sql request to check the token validity.
Is it still a good idea to make a full REST service, even for the website or to have a "normal" website and also a REST service API just for the mobile apps ?
Thanks
Oauth is a server to server authentication framework. Like it is between mobile app and your API server , website vs your API server etc. You can adopt an approach where , you generate only one access token for your website client instead of multiple access token for each user from the website. This access token is stored in your webserver vs user cookie in website.Ultimately the aim is to identify all the clients of your REST WS and your website is one of its client and a very trusted one.
This way you can cache the access token to avoid db calls (typically cache time can be equal to or less than token expiry time). Do explore the multiple grant types specified in the oauth spec for this
Regarding maintaining session for user in your website, it is not dependent on whether the back end is a REST WS or not, it can be handled in your website