I have a webservice with the name http://mywebsite.com/myapp/findname. The parameters it take is name. When i provide the name the return result will be the actual details of that person.
I have a worry about security in this instance. What happens if someone gets the Webservice URL (This can be got easily, by going though a web pages source). Anyone will be able to pass some data and retrieve information using my webservice.
So how am i able to avoid this ?
For security purpose u will ask a valid usertakon(which can be generated at the time of signup with random number), when u receive usertakon(as parameter) then first match this usertoken with your Database for verification that the user is valid or not, if user is valid then u give response otherwise restrict it at first level.
Basically,
U can resolve this problem by the following step.
First there is a login API . In that api you need to provide the some token in the response.
and change it if user request for again login.
Than u can request for token in each request . if token is valid allow him to access the API response. if the token is invalid show the invalid request
Related
I'm using OAuth2. Since it's a two step verification, shouldn't it give me an error when I try to make the following request? I haven't specified the client secret, but it still is sending back an access token that works to use.
http://localhost/oauth/authorize/?response_type=token&client_id=myclientid&redirect_uri=http%3A%2F%2Flocalhost%2Fmyredirecturi.php
I understand that I first need to ask for a request token, and then trade that in for an access token, but every time I make this request I get back an access token that works..? Although, I get an error message if I specify the wrong client id.
Looks like I forgot to disable the allowed implicit grant type. :) Works now.
I'm going to make a Rest API, this working in the following way:
user send an header with a token string
api check if the token is valid and if are available in a xml file
if yes, in this xml file I return the connection of database (there is also information about the user)
now I want store somewhere the information of the user that's performing the transaction
I thought to the header but how I can store some information on the header? There is also another way?
If the validity of token is too long.
You can use redis to save the user info corresponding to the token.
Something like this.
Further you can simply query using token to get user object.
{token : {user Object}}
You can write delete token script for deleting expired tokens.
i want to access token value form dropbox api programmatically
see above image in that at last there are token value i want to get that token value pragmatically. Right now flow is like below
Go to: https://www.dropbox.com/1/oauth2/authorize?locale=&client_id=a6sait9lgzwntkx&response_type=code
Click "Allow" (you might have to log in first).
Copy the authorization code.
When i perform above steps than above dialog is open but i want to get token value directly so is there any other way for getting that token value ? your all suggestion are appreciable.
Yes, if you can use a redirect URI, you can get that "authorization code" delivered to your app programmatically. There's a guide about this that should be helpful here:
https://www.dropbox.com/developers/reference/oauthguide#oauth-2-on-the-web
When using a redirect URI, supplied via the redirect_uri parameter, the authorization code is returned to your specified redirect URI in the code parameter after the user authorizes your app. Your app can then exchange the authorization code for an access token.
This is more of a procedure question question than a code fault one so please be kind if I have posted in the wrong place.
I have successfully authenticated a gplus user client-side so the browser is holding the google id ready for me to use. I now want to post some data to my website with that id as the user id but i want to protect it meaning I don't want just anyone with someone else's gplus id to be able to post to my web app (it has to be the authenticated user at that time).
Should I install the php serverside sdk and use that? If so how do i merge the client-side data with that?
Thanks
You're absolutely right about wanting to get the ID in a secure manner to make it hard to impersonate. There are two main options, both properties of the authResult object that comes back to the sign in callback:
Send the 'code' to the server. This is part of the OAuth 2.0 flow, and can be exchanged on the server side for an access token. From that you can make API calls as the user, and retrieve the user ID and other details. You can be confident who the user is, as only Google could have generated that code. This would involve using one of the client libraries to handle the token exchange.
Use the id_token. This is a base64 encoded blob of JSON which includes the user ID (and email address if you requested the 'email' scope). What makes it secure is that it includes a cryptographic signature, which the server can verify, so it cannot be created by someone other than Google. The id token can be used to get the user ID, and so can be used for looking up the user on the server, but doesn't give access to make API calls. The benefit is that it only requires up to date certificates for verification which don't change that often, so most calls require no further network traffic from the server to verify the user.
Which you use is up to you, but both will require some code on the server. In general, if you don't need to call any Google APIs from the server, or are concerned about maximum login performance then use the id_token. There's a bit more about that sort of architecture here: http://www.riskcompletefailure.com/2013/11/client-server-authentication-with-id.html
You can even combine the two. The first time a user signs in (when they see the consent screen) the code exchange will return not just an access token (for making calls), but also a long-lived refresh token, which you can store securely in a database. If you store that, you can use the id_token to look up the user quickly, but still use the refresh token to help with API access.
I am using Opauth for users to login with their social networking accounts for a commenting system.
After reading around this particular site, it appears that the token is one way to identify the user by storing it in a session. However, I've also read that it isn't necessary to use the token, a User ID would suffice.
My question is, what determines whether you use a token or the User ID is simply enough to identify the user?
The uid uniquely identifies the user, but the token and secret are used to make requests to the Twitter/Facebook API's after you've gained access to the account.
If you aren't intending to make any additional requests the secret and token will not be of use to you.
I'll try to explain you the purpose of Access Tokens in reference to the Facebook API.
A uid (User Id) is something that can uniquely identify a user on Facebook. For example: 1786565687 (that's me by the way). Whereas, an Access Token is an opaque string that identifies a user, app, or page and can be used by the app to make graph API calls. A User Access Token for instance is needed any time the app calls an API to read, modify or write a specific person's Facebook data on their behalf.
I've also read that it isn't necessary to use the token, a User ID
would suffice.
This is true but using a user Id, you an only obtain a limited amount of information related to a particular user. For example: https://graph.facebook.com/1786565687 will provide you only a limited amount of information for the user Rahil Arora (that's me again) and you won't be able to write or modify on my behalf.
Whereas, using a valid Access Token, you an even write or modify a specific person's data on their behalf. Because of privacy checks, the majority of API end points on Facebook need to include an access token and therefore you can't access there end points by just using the user Id. You need a valid Access Token in order to access extra information related to a particular user. For example: https://graph.facebook.com/1786565687?access_token={Access_Token} will give you a lot more information than the previous call.
what determines whether you use a token or the User ID is simply
enough to identify the user?
Well, as you can see, you can choose either a token or just a user id depending on the type of action that you're willing to perform.
You can refer to the links posted in the answer for further information.