Does this sentence from the documentation imply that I can get public data from the api without using OAuth?
"By default, your application can only access the user's public data. If your application needs to read more private data or change associated data, your application can request a larger permission scope through the authorization flow."
There are several API-methods for which you don't need to authorize.
Have a look at the API-documentation - for every API-method it is stated whether or not the call needs preceding authorization.
Related
I'm in the process of developing a REST API where users are able to have multiple accounts. User will be able to access the API via JWT authentication and accounts will have API keys allowing you to perform CRUD operations on models related to the account (Account and models are related in a one-to-many fashion).
My question is how one would implement this in a secure way? Stripe has similar logic and the API keys associated with an account are visible to all users connected to it, leading me to think they might be stored in plaintext or encrypted with a common key?
I also can't seem to wrap my head around how one would create a single controller endpoint that uses either a jwt token or an account specific api key.
I'm thinking it could be done by requiring an account_id on requests performed with the JWT and loading this automatically on API key requests but would this be the best approach or am I missing something?
Something along the lines of
public function createModel(Request $request)
{
if ($request->type === 'api_key')
$account_id = $this->getAccountIdFromKey($request->get('api_key'));
} else {
//Request is performed using user JWT
//Validate that $request has account_id set
}
//Logic related to saving Model here
}
Thanks in advance
Take a look into this example, it describes how to use a api key to authenticate a user via the Symfony Security component Official Documentation.
I could not find the documentation for the 4.* version of Symfony, it should be much different for that Version.
Or you could include the LexikJWTAuthenticationBundle which provides a complete support for a JWT authentication process.
I am writing a public rest api, that uses api tokens that are one per application that uses it. I want to give the ability for the client to create users of the application, but not restrict them with what a user should be.
So I have API_USERS that need a token to authenticate to do any requests to the api. Lets say its an api for messages. So the messages from one application will be identified by that token, but how can I let the application that is using the api to be able to create their own users so that the messages in the database, are first uniquely identified for the application and then uniquely identified for the different users of the application if the application has such needs.
My idea is that I can just add another field like MESSAGE_OWNER and let the user handle how to create unique token for his users and maybe use his own database for storing users. Would that be a good solution? Is there another way I am not seeing?
With there being rate limits should I ask for an increase when trying to get all access approval? Since my app asks the driver/ rider to sign in using their uber credentials will this help limit the calls to the API?
Thanks in advance.
Probably not, but it depends entirely on your purpose.
Calls to an API are usually done to get or update data on the home servers, in this case Uber's servers. As such, any Uber specific information you require will likely need to be accessed through their API.
Now, I've not reviewed Uber's API so if you can use the return from the login request to resolve all your needs then great. However, if you need to get data from their servers it would only reduce calls to the API if they require data returned on the login which can only otherwise be retrieved by making another call to their API.
I am trying to create a REST API using Java.
Now, for the front end, I am using socialauth, so that facebook/twitter/yahoo/hotmail/gmail users can sign in to the application.
After a user is signed in, he should be able to access the data for his account- I want to create a REST API that enables each user to access his data. I have understood the basics of creating a REST API using Jersey framework, however how do I ensure that only a user who is correctly logged in to the application, can access data via the REST API?
What I thought of is, I will store the user's email ID in session, when he logs in. And whenever he makes a request to the API, the email ID in session is passed as a input parameter to the REST API, and the REST API checks that data is asked for same email ID, as the email ID parameter.
Is the above way of thinking correct? What is the recommended/best way to implement REST API in the scenario as given above?
is there a way to fetch the venues search in iOS without the user entering his password or showing some foursquare oauth website?
I don't think that this oAuth makes any sense for this kind of request, it should be just an REST api like so "https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC"
but this one is deprecated =/
Any thoughts?
It's not deprecated, you're just missing the "versioning" parameter that specifies what version of the API you're trying to use.
Requesting https://api.foursquare.com/v2/venues/search?ll=-27.58818,-48.523248&client_id=JN00ABQBOCK5V54FQ1TWQFLOOIDU12UAZXURHXGXNK0ESJBY&client_secret=14ES1NXTCL1XC5HSLBUT4LWE4ROEDGNYKKWGGERZQGUKQ5JC&v=20111107 will remove the warning you saw in your response
Add a query string parameter to your request as follows..
&v=20111119 // Choose a proper version.
Update: this is actually a date. So make sure you send current date in yyyymmdd format against v parameter.
According to FourSquare's docs page on venue searching an acting user is no longer necessary:
Some endpoints (e.g. venue search) allow you to not act as any
particular user. We will return unpersonalized data suitable for
generic use, and the performance should be slightly better. In these
cases, pass your client ID as client_id and your client secret as
client_secret. Although the draft 11 of the OAuth2 spec provides a
mechanism for consumers to act via token entitled Client Credentials,
we do not currently support this.