I've got an application where back-end and front-end are served from different hosts and are two different applications (both Symfony 3 based).
One of them (back-end ofc) handles business logic and keeps users and their roles in it's DB. Back-end provides REST API to be used by front-end. I have no possibility to modify back-end code as it's not my project - I just want to create a front-end for it.
Currently, I'm trying to create front-end app in Symfony 3 but I'm not sure how to make the front-end app authenticate against a remote API and keep no user data (or as little as possible) on its side.
After passing credentials to the backend via REST API a token is sent to front-end application and following API requests (e.g. data the front-end app would present to the user are to be sent with token received after successful authentication).
My question again: How can I authenticate against remote custom (non-OAuth) API from Symfony 3?
And additionally: How to handle token properly later? (it has to be used while making every request after successful authentication). What is the easiest way to achieve this?
I've been struggling to find decent info (maybe a tutorial?) I'm a noob in Symfony :(
Most articles describe providing an API which allows clients to connect to it, not making a client app in Symfony.
What I found:
Symfony2 authentication via 3rd Party REST API - most relevant, though it describes a flow for Symfony 2 and the accepted answer describes what should be done only briefly
https://blog.vandenbrand.org/2012/06/19/symfony2-authentication-provider-authenticate-against-webservice/ - concerning Symfony 2
http://symfony.com/doc/current/security/custom_authentication_provider.html - probably the most on topic, however, I don't understand where will app keep it's users (is writing a custom user provider necessary in this example?)
You've already found the answer on your question. That's custom authentication provider. You can keep the tokens in your frontend app storage, and just authenticate them. On login, you should create the token via request to backend app, save it in your token storage and that's all. Then you only need to authenticate the token (just see an example of auth provider).
Regarding keeping user data in your frontend app, it's up to you. You don't have to keep any data, therefore if you'd like to show some details (i.e. user name and so on) you have to store that details too (or retrieve it each request - but that will impact the performance). At least you can use caching for that.
So the possible approach is:
On login(with login form or elsewhere), just authenticate user in login handler (create your own auth provider as described there - don't worry about Symfony 2, security component is almost the same - there are some incompatibilities, but the direction is correct). After successful authentication, store token in your frontend storage (also you can store some user details you need like name and so on).
On each request, authenticate the user using the token that's kept in your frontend app storage (that's another auth provider) - you don't need to send request to your backend app.
Related
I'm building a platform on .Net5 that will consist of at least 3 MVC web applications: User, Admin, Product. Authentication is performed on the User application where we can take a Username/Password to log the user in. The User Application also has the Forgot Password/Reset Password, etc functionality on it. Authorization is claims based. Based on this document I believe I would fall into Figure 9-2 Authentication by identity microservice, where my other microservices are web applications rather than APIs.
The issue I'm running into is trying to figure out the proper way to implement this.
Do I use JWT or Cookies for this? The article above does have a link for cookie sharing but wouldn't JWT be appropriate?
If I did use JWT, how do I pass it back to the server if I used something like #Html.ActionLink? Or is it expected that I would be using a front end framework like React and thus making any calls back to the server manually?
Again, if I'm using JWT, how would I pass it from the User application to the other applications?
I'm working on a project with a RESTful Java backend and a Vue SPA front-end. Whilst figuring out how to do user authentication I came across JWT-tokens and since it (sorta) was what I was looking for I recklessly implemented it.
Few weeks later I realize that because the content being shown on the client side, depends on the users role, the client of course needs to know the users role. For obvious reasons I don't want to store the users role inside my client.
My question: I could create a request on the server that looks at the Authentication header and returns the role, but would this be save? If not are there any common strategies when it comes to roles and JWT-tokens? Or should I forget the JWT way of doing things and implement another kind of authentication entirely?
JWT is the common way to Authenticate users with SPA as Frontend + REST Api as backend.
You definitely should not store your Token Secret in frontend app.
You definitely can do kind of /user/roles endpoint in your API which will return the list of user's role.
Point 2 solution is 100% safe. Why? Even if someone will hack your frontend app to show the content which they should not see, your backend is checking Authorization at endpoint, so they will not get/put/change any data which they have not privilege to access in their JWT.
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