According to Foursquare's dev site, venue details do not require user auth:
HTTP Method GET
Requires Acting User No (learn more)
Modes supported foursquare, swarm (learn more)
But the example uses a oauth token and if you try searching with your client credentials, you get a 400 response.
https://api.foursquare.com/v2/venues/4b522afaf964a5200b6d27e3?client_id=MY_CLIENT_ID&client_secret=MY_CLIENT_SECRET&v=20140714
returns:
{"meta":{"code":400,"errorType":"invalid_auth","errorDetail":"Missing access credentials. See https:\/\/developer.foursquare.com\/docs\/oauth.html for details."},"response":{}}
Does anybody know of a way to get venue details without having user logged in?
Sigh
The issue was with my code. I was putting my client ID in twice.
just so everybody knows, the above works :)
Related
Team,
I have an requirement like i have to support to my partner (third party) portal to call us directly by making api call with credentials from their browser.
e.g.) Partner portal browser makes AJAX Call with below:
URL ---> https://example.com/request
HEADER ---> user_id : foo
HEADER ---> password : mypasswd
payload ---> {
"request_time" : 2232876435,
"request_name" : "get_user_info",
...
...
}
And their browser/portal is accessible/used by untrusted users of theirs. So now problem is since the call is from the front end; end user easily can inspect the browser to see the network api calls along with credential we have given to our partner to authorise at our side.
So i am planning to give suggestion to partner by asking them to encrypt the payload and headers in their portal backend server and render the encrypted information in the portal like below.
Encrypt (payload) using mypasswd.
Encrypt (password) using request_time <NOW OPTIONAL TO PASS>
So now,
e.g.) URL ---> https://example.com/request
HEADER ---> user_name : foo
HEADER ---> password : ENCRYPTED<mypasswd> <-- OPTIONAL
payload ---> ENCRYPTED<
{
"request_time" : 2232876435,
"request_name" : "get_user_info",
...
...
}
>
So in our system we will decrypt payload with mypasswd retrieved for user_id foo. so if decryption is successful, then the request is from valid resource.
Now the end portal user cannot understand the request from browser inspection.
NOTES:
I can't suggest my partner to call from their backend.
From the request payload i can identify repeated same request through unique transaction id, so they can't resubmit the same request. Hence avoiding replay attack.
Questions:
Q1) Any flaw or suggestion on this solution?
Q2) Is it possible to identify the decryption using passphrase is success or not in java? I am new to encryption, so could you please share any code or link to achieve this?
yours thoughts much valuable to me.
TLDR:
References:
Basic encryption details
https://blog.storagecraft.com/5-common-encryption-algorithms/
https://www.veracode.com/blog/research/encryption-and-decryption-java-cryptography
https://gooroo.io/GoorooTHINK/Article/13023/The-difference-between-encryption-hashing-and-salting/2085#.W2L_KdgzZD0
Java Encryption
How to encrypt and decrypt String with my passphrase in Java (Pc not mobile platform)?
Java Security: Illegal key size or default parameters?
Identifying decryption is successful through this exception:
Given final block not properly padded
EDIT: I misunderstood the question. If the information is encrypted by the third party before it reaches the end-user then this approach is generally safe. Replay attacks are the main thing to look out for. If the request being made is idempotent then you don't really need to worry, but otherwise you might need to implement a short-lived database for used tokens along with an expiry time or something similar.
You are solving this problem the wrong way. Having the end user make this request to you on behalf of the third party is silly - if the request comes from their browser then by definition they control the information they are sending and the way it is sent. Encryption does nothing to solve this since the encryption logic is also client side.
The solution to this problem is to eliminate the end-user. The request should come directly from the third party to you. This might be from the end-user making a request to the third party API or it might not - it doesn't matter.
I am trying out get the access token from the super user so that I can the same to create new users in key cloak, I have deployed keycloak in wildfly and when I try to do the get call, I am getting Invalid user credentials as response,
How to know the actual credentials?
And when I try to update the password from the console, I getting the error message like below.
Since I am new to this and din't find enough information from internet also, any kind of help will be appreciated .
Updated:
Now i am getting new error description as Parameter client_assertion_type is missing like below. What should be client_assertion_type here ?
This keycloak help page describes the most likely reason for the second error:
Q: When logging in, I get an error: *Parameter client_assertion_type is missing [invalid_client].
A: This error means your client is configured with Signed JWT token credentials, which means you have to use the --keystore parameter when logging in.
Alternatively you can disable using JWT tokens for the client in Keycloak.
For your information, the client_assertion_type would probably be urn:ietf:params:oauth:client-assertion-type:jwt-bearer. But then you'd get another error because the client_assertion is missing.
If ccp-portal is a confidential client using client authentication with signed JWT then the Keycloak doc states that
During authentication, the client generates a JWT token and signs it
with its private key and sends it to Keycloak in the particular
backchannel request (for example, code-to-token request) in the
client_assertion parameter.
I guess it's not possible to generate a JWT with PostMan.
This is meant for backchannel client-keycloak communication, not for
user authentication.
Solutions
You can use the admin-cli as client_id instead of your ccp-portal client. The admin-cli should be in the list of clients configured for your ccp realm. You can see that from the Keycloak interface.
Another option is allow direct access grants in ccp-portal client config.
Finally you could use ccp-portal client in your application configured with one of the Keycloak client adapters, instead of POSTMan.
As subrob sugrobych mentionned, parameters should be passed as form-data.
first of all, when you are posting data to keycloak over a rest client, you need to input parameters as form paramaters, and not as query parameters. This is why you are getting this strange error of not providing parameter grant_type, when you obviously are providing it. Same is valid for accessing keycloak api via code.
Next thing you need to think about are roles for your superuser. You can assign realm roles and client roles. There is a client named 'realm-management' which contains roles which would normally count as "system roles". You will need to use them. When you are getting HTTP code 403, it means, that probably your user is missing a role from this client.
A common SO question, but no specific solid answers.
My setup:
I have a website running on Classic ASP with backed DB. Unfortunately, no SSL Certs are available
I have an Android application that will send a Google Volley to request data from the site using a bespoke but simple API
Currently:
I am still in testing, privately, so currently I just access the site as such:
On the app, the user enters a UserId and Password once.
User navigates to a Fragment which is associated with a specific ASP Page which will return some data
A Volley is sent to /mysite.com/_api/apage.asp?m=md5hashhereabcdefghijk
The server searches user records for a matching hash (built on UserID+SALT+pass). On matching record, it uses the found userid as the User's ID
apage.asp does some sql queries and returns a JSON object
app receives this JSON response and parses.
The problem:
Anyone packet sniffing, or MITM, would be able to plainly see the URLs being accessed (and server responses) and be able to replicate the query via their browser. This is what I'm trying to stop. Any SALTs or secret keys in the app would be easily seen by decompiling the APK.
Issues:
I've read all sorts of different solutions, but none of which really fit my environment. I can't use ASP session variables (RESTful being stateless), I cant use HTTPS(SSL/TLS) as there are no Certs on the Server. I can't use an App-based password as this can be decompiled and easily seen.
I appreciate that you will never get something 100% secure, but can only make people disinterested in hacking a system, or not make it worth while.
Proposed solution:
I want some feedback/thoughts on the following proposed method:
Each request will have its own handshake to authenticate the app
This will go as such:
User opens app for the first time and enters UserID/Password. This will remain with the app until it is uninstalled (or logged out), but I intend to keep the user's app logged in
User navigates in the app to a Fragment that corresponds with a specific page on the server
Volley is sent with :
UserAgent HTTP header 'some value'
generate the same authentication hash for (userid+salt+pass)
encrypt this hash with a public key
one query string /apage.asp?q=abcdefghijk.... sent to server
server decrypts using its private key
server checks this hash as I do currently.
page returns plaintext JSON values (not encrypted)
The same problem happens here whereby a MITM or sniffer could replicate the URL and get the same information back
A Second Proposed Solution:
Would it be better with every request actually starting with a whole handshake?
App sends volley to server requesting a handshake (HELO)
Server gross error check with UserAgent HTTP Header
Server logs the timestamp and IP of the request and generates a unique random code
App receives this code and builds a new hash using that unique code as a Salt
App sends second volley to /apage.asp?m=MD5(UserID+UniqueCode+Password)
Server Gross error check with originating IP, timestamp+-tolerance (30 seconds between the two requests?), UserAgent Request Header.
APage.asp uses this hash to authenticate the request, providing previous steps have successfully passed.
APage.asp returns a JSON object, as requested.
Server flags the log of originating IP/timestamp as EXPIRED, or, just remove the record.
This initial step would make it a lot harder for a sniffer or MITM to replicate the URL calls, as A) Each request would have a randomly returned code B) each code/hash combo can only be used once.
The only thing I can think of is someone decompiles the App, and sees the method of handshake, so could try to replicate this. However, the username/password hash would never match as that is the only thing they cannot get from the hash (as it is salted with the random code)
Thoughts? Could it be improved with some RSA public/private key cryptography? Could I generate my querystring apage.asp?m=abcdeghi..., Generate an MD5 Hash of that, append onto the end, then encrypt before sending?
Many thanks in advance
My Application requires a Siteminder SSO login. I am able to capture the SM_USER which is the Employee Id by
request.getHeader("SM_USER");
Now I want to capture the Employee Name which is stored in Cookie.
I used request.getHeader("Cookie");
The cookie which I am getting is like
lcid=1033; IDEALDOMAIN=53AvKXzgyShYOE5+I4sX4Q==; SUPERUSER=False; ADIDMAPPINGFLAG=7LQlj8/2nvgLQlH4X/M4Gw==; INITMAPPINGSTATE=True; LDAPVALIDATIONFLAG=53AvKXzgyShYOE5+I4sX4Q==; SSOCONTENTNAME=IXK93MPqLZSIGwzx7YZ31XI8LtsJuLAActhQvcJy7sw=; SSOCONTENTEMAIL=Pym0Td3ayVI/gasQDYx0GJGt78jalJIJGLlFLVGsod8=; EID=AljFH+Zu6YpIYtFVw7TEZw==; IDMPROVISIONED=True; AD=Uyv5wIQS5rx76pd0hBocfg==; ACTIVEVIEW=vopKOOSRtqVJg2cbvwFkYg==; AMP_Session={"**username**":"**xxxxxxxx xxxxx**","opened": true}; JSESSIONID=0000DW8l91J8oZilIKjHYvb_Ahi:19t5pcqiq; SMSESSION=CC9Ac8JxZgpw+MsV6jIUKKjRtm2QCzBhon7hTZSfab/ceK0ZKij8SWXKN2D03jVA+KaGGrGPKoKY/Y3H34i9ymeNu9Ff7vtWhxbSekIzYc9KNQc0lYwxs/eWX0YKVDCZzakh5kR6n78UY/IOMQQN1p8mK2nZ2E7JI8vQDhT1o/IBHbIjfbS+o/a4r+IoUvrA5QcVBSHTeK8SifojnhSVWwi6kl/MQzmlDCuznDiCZpR9FR4k84BtNhArbME2Iq5lvZo7JeLnIFgqva4QqgVYh5fqbdme7b0YqzOvfRJoEHTn2dHYbPw0cQBsxaHRE49/vNrOL0VB6IOTUsD7rq8HL+WXhyaYp2kZLmvsroWcdGkikSwyp/u+p4I0Weeg+vqr8NhD6h4M/EYTEFKpB6nRhavj5sGnG5I2L9L66KNL3cPvU60YtTvUA4i0X/yBys7KI8mwHYUCA1vH/OUWVDW3Q0aOLN1ZF53G2vwBCYoc5EuYZ/Wg6SaUe5WOu1J8QS7LL7G1H5QqzojrcOOMWhqtjdkJOznODh4tuQieoB+TSkt7z/XHnUeqiagH8MCfF4zsd8pVXDsnc7of+RZpq/VKbTCXPQHP21ncNnB4Z8Miqnn5EMmAKdmJopZ/petU4UvNttGFoU4jJQl6ZgSEyrvqBnQFFVf0HQtqnt3zT64JajVrlFLITT/+wd//dAHsqtbLMLQcrsCU9aWRszP5toLXMn2rj1n8dRkcDbYwoSA5PWqSiHM3RcbKlO7Ej7Oe4FqOwITKde4yLE211JmMEEPvH42Bvg+1H/OrUJVQ3YfgkRFKu12oL5BubfjveknmK4r8wp8r3LTq/Rz58zkiwUj1J0qNAQ5BlHbL53vJdBZebQT0lpjTQ2KTOi96JlPkWhR2AnG71ZaIbfUsWz9QPYH55zc9KzbJE0AreyD/eJG9XcSkP6cV7gjsUDCUZk2i+H2iqO3tNQDMgUuZb65i7+CQKWlYixHYuo66zvrUql//1hdm8YiBDzNPRm4SIVKOcZkPk/H9MQYnTWa5fKppDVShcyCSNF6YME8038qg5mv5m7oF+0AfyxmzHeJ+Ddvy95NO
Now How can I get the username from this Cookie
Just like you are using request.getHeader("SM_USER") to obtain the userid, the usual suggestion in the Siteminder world is to use the so-called Response for Siteminder to help you retrieve whatever user attributes you need, in the case the Employee Name, and make them available in the Header for you. In short, you would need to ask your Siteminder administrator to configure this for you.
Since Cookie lives on a Browser, so unless the Cookie is encrypted, the user on the Browser would be able to tamper it and render the Cookie useless. If a Cooke is encrypted, then your program would need to know how to decrypt it and hence you would have a far more challenging task to do.
I want to get users' access_token by using Google Drive SDK in JAVA.
I completed to get access_token when user log-in first time. But, I really want to direct-login. I know access_token be expired, so 'refreshToken' can be my solution. But refreshToken is always 'null'. How can I perform direct-login? Many advices welcome.
You need to separate "login" from "access drive". Once your application has an access token for a given user/scope, it can access Drive on behalf of the user. There are two (main) ways your application can obtain an access token.
It can request access which will involve the user being logged in to grant access.
In step 1, it can request "offline" access, in which case it will be given an access token and a refresh token. It can subsequently use the refresh token to request more access tokens without the user being present.
I suspect that you want to do option 2. This is described quite well at https://developers.google.com/accounts/docs/OAuth2WebServer#offline
If you have tried this and you having problems, please paste your code and the http trace so we can look at the problem with you.