I've read through these and many linked documents for the last several hours:
https://cloud.google.com/storage/docs/uploading-objects
https://cloud.google.com/storage/docs/authentication
Yet, I still don't see a way to simply upload a file to Google Cloud Storage from my web server (not browser), without using OAUTH or some type of short-lived token. Since I'm uploading from my secure server, I would think I can just use an API key or some persistent service credentials or client secret directly without having the overhead of extra OAUTH calls and refreshing tokens. Is this not the case?
Probably doesn't matter, but I need to use the REST API because my server is a garbage platform that doesn't support any of the client libraries.
Related
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.
I have a set of REST APIs that are secured by oauth 2. I need to access them from an Android app and a webapp.
Accessing the APIs from android app seems pretty straight forward for me to implement. What I am unable to understand here is - what is the correct and secure way to access the same APIs from a webapp?
I am thinking, I shouldn't be making any direct calls to the APIs from the browser, using some JS library, for it seems to me that it would be pretty insecure. Instead, I should keep it all traditional, by submitting requests to the web server and then letting it make the REST API call. This would be similar to the method of making REST calls from Android.
Am I correct in my thinking/approach?
Accessing your API should be the same no matter where the request is coming from. You just use an Authorization header with bearer scheme and stick the JWT token in there.
The way you get the JWT token is different though, as I explain in this answer. It all depends on how much you trust the client application.
If your client is a web application that queries your API from the server side, you can use the code authorization grant and get an access and refresh token for your API.
If you want to access your API from a JavaScript application, you have no way to hide app-keys or refresh tokens, so you should use the implicit grant.
If you know how to store secrets securely on your Android client, you could use the resource owner password grant.
The code authorization grant is definitively the most secure as it's much harder to compromise a server application than an application that runs on your machine.
Well i have a scenario where i have a rest api built on laravel and controlled by JWT. Then i use another route to request the api for the token. But once i receive the token after giving the login credentials where should i save the token?
I think it should be saved in the client's browser, so on the next request we just fetch the token from the browser and then go through another request. Saving the token in the browser will also give the advantage with scaling the server, because if its on the server's session not all the servers will be in sync with this session data.
Now i want your opinion on this, should i store the token in a cookie or in the browser's LocalStorage? I know how to store it in cookie but dont know how to store in localstorage with js. It would be helpful if you could point out to any tutorial for this.
There is a good article here on local storage vs cookies with JWT. They recommend cookies because of XSS vulnerabilities when using local storage.
It is also worth pointing out that if you are using the Laravel JWT Auth package, that the token is still being stored on the server (using Laravel's cache system) by default, and so will not scale across servers. You should be able to change this with the storage config option.
My plan is to develop an application which creates user recommendations based on the user´s Facebook data (age, likes,...).
In this Figure (sry, i am not allow to post images directly) you can see the flow of the application. Is this the configuration "Login on Client, API Calls from Server" from the Facebook Documentation?
I am not sure because the Recommendation Server, which calls the Graph API, is not the same as the Web Server. Additionally, in the documentation it is mentioned that the Client forwards the API calls to the server. However, in my case the Web Application (Client + Server) does not know which API calls the Recommendation Server makes.
Is my project feasible? If not, how do I have to adapt my plan?
I don't see a problem here if I understood correctly. Have one web server to the OAuth login, exchange the short-lived Access Token for a long-lived one, and store the Access Token somewhere in a (NoSQL or SQL) database such as Redis, MongoDB or MySQL where both web server and recommendation server have access to.
Then, the web server needs to trigger the recommendation server to do the calls he needs after the Access Token has been stored.
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