I have one Laravel app with a GUI where the user logs in based on the data from a MySQL database.
When the user logs in, the server needs to make a request to a specific endpoint of a 3rd party API in order to get a token. This token comes in the response of that request and, since it's some kind of a session token, it renews from time to time (which implies that this same request which retrieves the token should be called if a particular error is thrown).
In some specific views / routes the associated logic in the controller implies a request to one or more endpoints of that 3rd party API with the previsouly acquired token in the body or in the headers - depending on the endpoint.
I'm mostly concerned if someone gets access to that particular token. If that happens, then they could interact with the 3rd party API and do an unwanted mess. So I'm ok if the pages or operations take a little longer as long as the implemented procedure is very secure (the risk of the previous scenario to happen be extremely low).
What's the procedure I should aim for? The desired answer would take advantage of Laravel "machineries" and refer where and how this token should be stored.
In Web Development this scenario usually handles with CSRF token, to ensure the Right user has sending The Request.
from your question i assumed that:
your front-end sends request to third-party Api.
if your third-party library supports CSRF Protection
My Recommendation is to use an Proxy Design Pattern:
Front-end invoke a route in our back-end.
your back-end route (plays proxy role) requests third-party library with session("third_party_session_token")
Third-party only Responses your back-end.
Back-end return response to front-end.
So in this way, The Third-lib Token Will remain only in Back-end.
Third-party Api-tokens are stored in users session space .
you can use laravel Encryption, if you are worry from session data leakage:
session->put("third_party_api_token",Crypt::encryptString($api_token));
and retrieve it when you want to whitin third-party:
$api_token = Crypt::decryptString(session()->get("third_party_api_token"));
before Encrypting anything you have to generate a key using:
php artisan key:generate
Related
I have a monolith web application powered by Laravel. Users access different forms and some of them have button on them that executes Ajax call to the back-end (example relative endpoint: api/external/get-current-temperature). A back-end function that handles the request than connects to an external service via API and obtain data, writes some log in database and pass data back to requestor (front-end user). But in order to execute any API call it has to authenticate and obtain a Token.
Question:
I have multiple users that can potentially request api/external/get-current-temperature at the same time. How should I handle authorization/token? Should I store it in database and check its expiration time before requesting a new one or what? How would I refresh it? - The external provide has no specific function that could be utilized to verify token. But I know for sure the token is valid 60 minutes.
The users of your application never have to be mixed up / mistaken with your foreign API. You can and should provide you own mechanism (i.e. tokens) to authenticate any users. If users are authenticated the external API is used, else an error-message could be provided by your application.
As users also fill several different form it's quite possible that you save some user-data. If every user has own authentication credentials it's easy and much more secure to provide only the user's own data. If you use for every user the same authentication token in your own application you might get the situation that one user can see data from another user.
So see it like this:
You / your application is the user of the external API, therefore you need only one authenticqation token for it. Your application users use the external API as a service and as that you should provide it in your app. The data though that are provided to the service might differ from user to user.
Example payment application:
The API is always the same, you as developer get an API key, but the payments are for every user of your application differently. As developer you might never even able to see, store or track the user-data that are exchanged between the foreign service and the user, but your app serves as hub and provides perhaps also some products or services that are considered in any payments.
I am developing an Ionic App which consumes data from a Laravel 5 RESTful API. All the connections are protected (GET, POST, etc.) by username/pass and user roles, except the user creation.
My first doubt about security is to disallow connections from outside the App, avoiding thousand of user creations, overloading our server resources.
My idea is, when an user installs the app and opens it for the first time, to create a secret token which will be sent in every connection. Then check the device UUID and the secret token to ensure this is an authorized app.
What do you think of securing the connections this way? There is a better idea?
You need to look a JWT (Jot) JSON web tokens, they will solve the security issue. This can contain user id and other data like access level. Not things like security information or card information.
When a user authenticates Laravel sends them back a JWT which you store in local or session storage this replaces backend sessions.
It is generated by the backend using the parts that can be decrypted by the frontend and using a secret key to encryt the signature, if any of it is tampered with it will fail and deny access.
Every request angular will append the token to the header using a request interceptor and Laravel middleware will decrypt it and allow access to the route they need or return a error code '404' maybe.
If after install this authentication layer you can limit usage at user level on the backend.
But this should sort most of your issues, it a bit of a change in thinking but it does work and it solves a lot of sessions issues you get with ajax calls and it make load balancing easier because all server are looking for a token it can manage.
I was also encountering the same problems. But after search in google for a while I came to the conclusion that you can put up several walls against hacker, but for someone who is hell bend on hacking your app(ninja hacker) will find ways to use your app in malicious ways.
I also came across various ways you can protect your backend server(after google). These step generally make it difficult to use your app maliciously.
You can encrypt strings url using some algorithm and use encrypted string in program ie. https:\google.com\ is encrypted into something like \h09ae\hff00\hebab\h.... then in program String url ="\h09ae\hff00\hebab\h.." This way someone decompiling the app can't find your server backend url. In this case you need to decrypt the string url before you can use it.
Send sensitive data using HTTPS and inside the body of the request
You can verify if request is coming from the device by using google token. For this you will have to use Google API Console. Refer this link for proper android tutorial on this topic.
Lastly, sign key used when you create your apk is unique and ensure that your apk is not tampered with. So generate hash key of your sign key before it is upload to google play and save it in your server and programmatically get hash value of sign key and send it with very request to your backend.
Hope is helps you..
I am looking to implement SSO in all my future php/angular applications. I see there are services (Auth0, oauth.io, etc) that are sort of the middle man of an SSO app and there are protocols such as OAuth 1.0/2.0 but in regards to creating a custom SSO solution (using aforementioned OAuth protocols, I assume), I am a little foggy on the complete flow of the process.
What I do get:
App gets Access Token
(optional) App validates Access Token
App (with Access Token) gets access to a particular API and returns result. For
example, Facebook profile information.
What I don't get:
What to do with that information once I have it. Do I retain the access token and request information from the API source each time they login? How do I relate my own application data to the API data? Would I create a different kind of user record that just contains the access token and application's userid?
Do I retain the access token and request information from the API source each time they login?
If the token does not expire, you can hold on to it in a data store and use it with each request. Many times, though, the token will expire, and you need to request a new one each time you start a session. In this case you'd probably store the token in memory instead of a permanent storage location.
How do I relate my own application data to the API data?
I think we'd need to know a little more about your application to answer this question.
Would I create a different kind of user record that just contains the access token and application's userid?
Again, we'd probably need a little more information about your application. If you were persisting the token (in the case that it doesn't expire), then you need to make some considerations about how you want to store it. If not, you can probably just put it into a local variable or session.
I need to create a REST api to authenticate a user the first time and retrieve other information based on this user for subsequent calls. If I'm not mistaken Restful services are stateless and therefore there is no need to store user information server side. My question is how can I guarantee user authentication for all the subsequent calls without a session?
This service is needed to create an android app that can display information on mobile.
You could use OAuth which is a widely used standard.
Another option is to use BASIC authentication over SSL. Any decent HTTP library would support BASIC auth. The client will be challenged the first time the request is made. Subsequent request need to send the BASIC auth headers over a secure line.
The there is the approach where you pass a secret to your client and use HMAC-SHA256 to send a hash of the URL params over to the server. Amazon does that and there is an article that covers how this is done. It is not as complicated as OAuth.
There are many approaches available but IMO your best best is to generate a AuthToken server side and return that to the client upon successful login. Then the client includes this on every request down to the server.
What I typical do is create a MD5 hash of a secret key and the the user's id- user's username - user's password - and the current date time. Then I store the token and the current date time in the db. on look ups after that I decode the token and compare the data points against the db values and if they match the user is good. This way is stateless and easily scalable.
I'm writing a RESTful Webservice with the Slim Microframework and use GET for reading data from a mysql database (select query) and also POST/PUT/DELETE for insert/update/delete rows in the database.
My question is now, is this not a big security issue if everybody is able to write or delete data in the database? But how could I prevent this, I thought the ST in REST stands for state transfer (so the webservice is stateless), which is a contradiction to a state like being logged in or not. And if I would pass some login data with the client which is allowed to write in the database, couldn't a bad guy catch the logindata and fake requests with it and for example delete all entries?
So, whats the normal way to go with this, the only Slim Framework examples I had found always show the route examples, but not how to secure it.
Are there also some opportunities in the Slim Framework to implement this what I need? It should be as easy as possible and the request should be responded nearly as quick as without an authentification or similar. There are no sensitive data like passwords, for me it would be enough that not everybody with a cURL commandline tool can delete all rows or things like that.
Would be great if anybody could explain me what to do and/or give some examples. I also need to know, what I maybe will need to change at the clients which are allowed to send the requests.
Lots of thanks.
Each request has to be authenticated and authorised.
People often get tied up with the word 'stateless'. This really just means that from one request to the next, the RESTful service has no prior knowledge of the users state.
BUT, the service is obviously allowed to be aware of the authenticated user that has just made a request, else how would it decide if it should allow access?
Therefore, you can 'store' the authenticated user in some variable during each request. Then it's up to you how you use this information to authorize the request.
I like to keep it simple and have all my users as a resource in my URI chain. They make requests like users/{username}/someresource.
I authenticate using http basic authentication (over SSL) and authorise based on the URI. If the request failed authentication, its a 401 Unauthorized Request. If the URI {username} and authenticated {username} do not match, the request is a 403 forbidden. If it is authenticated and authorized, the request is allowed (http code dependant on http verb)
Now that's the web service covered, now on to the web service client. This of course HAS to store state, otherwise your user would have to log in every time they make a request.
You simply store the users session in the application (as per normal session management) with the addition that you store the username and password (encrypted of course) in the session. Now every time a request is made, your web service client needs to retrieve the username and password, and send it with the request to your web service.
It will be stateless, in the sense that there won't be a session or a cookie, really. You'd normally issue out a key that would be required for INSERT/UPDATE/DELETE.
It is then up to you to pass the key with each request and to determine when a key should expire.
It would be as safe as normal http authenticated sessions. These use a cookie etc to authenticate the connected user to the stored session state.
A stateless service would be no different - the token is passed to the service just as a token is stored in a cookie for normal http. If you are worried about sniffing (IE man in the middle attacks) you would secure the link via SSL.
The authentication token generated by the service would be encrypted and would include a salt which is also verified on the server for each request. You could also limit the session time to suit your paranoia, and also check changes in source IP, user agent etc and expire the user's token if these change.
I recently ran into similar problem. As recommended by people here, I have decided to go with OAuth Authentication.
I am using HybridAuth A php wrapper for OAuth and out of the box sign in solution for Facebook, Twitter, Google, LinkedIn, etc.