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.
Related
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
I am making a API based web application. It will contain various users like normal users, admins with webpages with tables for updating, deleting, showing stuff. There will be obviously many pages and access will depend on scope of user. I am confused and stuck at point that:
Should I generate personal access token with a scope every-time a user logins and use that for checking user's group(if it has permission or not) for giving access to webpages and for making some requests.
OR
Should I use CreateFreshApiToken Middleware for requests and I should just check user's group while logging in to give him access to some webpages.
I hope you understood what I'm trying to say.
And CreateFreshApiToken middleware attaches a laravel_token cookie to outgoing responses. If I'm using AJAX, does that work? If not, does that mean I will always have to pass access token with request?
I would go for the second scenario and use the CreateFreshApiToken Middleware, because scopes are in a certain sense subordinate to the user groups / user rights / user roles in your application.
For example, a user can have the rights to place and view orders once logged in to your application. But, developers of for example a mobile app consuming your API, could decide to only give users logging in to this app rights to view orders, i.e. the orders.view scope and not the rights to place orders. Compare this to for example a Google API. As a user of Gmail, you have the rights to read and delete emails, etc. But when you develop an app consuming the Gmail API, you could decide that the app only needs and only will ask the user for the scopes that are needed to read emails.
Managing the whole authorization layer in a Laravel application with scopes is therefore very thin. In most cases it is better to separate the authorization layer of your applications (user roles, rights etc.) with the authorization layer of your API (scopes).
The CreateFreshApiToken middleware is meant for consuming your API with JavaScript and AJAX. The laravel_token will be attached as a cookie to each AJAX request after the first GET request that is made to a web route after logging in (a request to /home is made automatically by the Laravel Auth scaffolding after login). Description can be found in this part of the Passport documentation: https://laravel.com/docs/5.4/passport#consuming-your-api-with-javascript
Personal Access Tokens can be seen as API keys. API consumers can use this key to authorise with your API, without going through the OAuth2 flow. You would have to create a proxy from your JavaScript application to your API to make requests with this token, which would be very strange.
Two questions:
Question 1.
We need to manage 4 playlists of a Spotify user from our back-end (PHP) (without user login).
Visitors of our website can submit multiple of their favorite songs to our websites. Based on that, we create and manage 4 playlists which contain the ‘top most submitted songs’. We want to automate this process from our PHP back-end without the need of manually managing the playlist day to day for a period of multiple months.
We would like to use the Spotify API for this, but a user access token is needed to access and manage user playlists. We created a proof of concept, which “simulates a browser with PHP”. We log in, retrieve an authentication token, request an access token with the authentication token and then perform the necessary API calls – all without user intervention.
This method works, but we suspect and know this isn’t 100% the way to go :). We’re not after abuse of the API or whatsoever, but how can we periodically automated manage these 4 user playlists if this isn’t the right way?
Please note our back-end is Apache – PHP based. We could also use NodeJS, but then again, this isn’t the way to go either.
Question 2.
Users submit songs to our website. When the user types in the search field (song title / artist name), after one second we perform an ajax call to the Spotify API and show the search results based on the input. Taking into account the amount of visitors expected on the website, this might cause a lot of traffic to the API.
The docs (https://developer.spotify.com/web-api/user-guide/#rate-limiting) aren’t very clear on the applied rate limits. Is it possible to give us a better indication of these rate limits since we want to prevent this from crippling our website?
Thanks in advance.
Question 1
If you want to create playlists in a certain user's library you need to that user to grant those permissions to your app.
In your case, you would implement the Authorization Code flow to obtain both refresh and access tokens.
Store the obtained access token and refresh token, use the access token to perform the requests, and renew the access token whenever it expires using the refresh token.
If you are going to manage those playlists in a user you own, then there is no need to show any login form to users. Log in once, and use the fetched tokens in a script that will periodically make changes in your user's playlists.
Question 2
The limits are not specified on the Spotify Developer site at the moment, but they API should be able to handle your search requests. If you want to be extra-safe, authenticate your requests so they are limited by client_id basis. To obtain a token like this, that doesn't contain any user's information, you can use Client Credentials flow.
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 have a requirement for php script which works as below.The Database is having list of some 20 twitterIDs.Webapp should be able to post a tweet on behalf of any of the twitterID given in the list.This happens back-door that means no user interaction will be involved like redirecting to Twitter Authentication page to allow twitterApp to access some stuff and user will accept to allow access.User doesn't know about this back-end operation.
My questions is :
Is this possible / feasible ?
If possible, how should i approach the development roadmap . My technology is PHP based and involves REST APi integration to a smartphone client.
Looking forward for some deep explanation.
You need more than just the twitter IDs to post on their behalf. They will have to authenticate the application first.
This generates two tokens OAuthToken and OAuthTokenSecret, which can be stored in your database back-end and consequently, be used from your PHP back-end to post on behalf of the user, till the user deauthorizes your application, at which point OAuthToken won't function anymore.
Twitter OAuthTokens do NOT expire, but the user can revoke your access.
You can implement the above in PHP using one of the Twitter PHP libraries
At some point the user will have to know about it, they will have to authorize your page the first time (you wouldn't want someone to post on your twitter feed without you knowing about it right?).
When they have authorized your page the first time, you can store the OAuth token you receive at the end of the authentication process and use it later on to post tweets, without asking the user to authenticate herself again, for as long as the token is valid.