How I get the following 3 Test credentials to setup sandbox
MID (merchant_id)
Secure key (used to determine hash)
Secure key id (merchant_key_id)
I got payzippy php-sdk from below mention URL but need test credentials to run this example to understand it.
https://github.com/payzippy/php-sdk
For the merchant id and secret key, you will have to reach out to us at 080-49697070 or contactus#payzippy.com. We will generate one for you and also assist you with the other processes.
Happy to Serve!
Team Payzippy.
Related
I'm getting started understanding what's required for Cybersource's Flex Microform integration. But to start with, I'm hoping to be able to see a valid response using my merchant ID, shared secret key and the general key that comes with generating the secret on the cybersource api reference page: https://developer.cybersource.com/api-reference-assets/index.html#flex-microform_key-generation_generate-key
This is using the HTTP Signature method and ChasePaymentech (default) processor.
If I use the default settings they supply and choose to do a test POST to here https://apitest.cybersource.com/flex/v1/keys?format=JWT&
The JSON response is good with no complaints of authentication.
If I try to do the same POST with my test environment merchant ID and keys I generated in my merchant environment here: https://ubctest.cybersource.com/ebc2/app/PaymentConfiguration/KeyManagement the POST response will return a 401 with this JSON:
{
"response": {
"rmsg": "Authentication Failed"
}}
Is this developer.cybersource.com site a valid place to perform this kind of test? Are there any other steps I need to do in the merchant account to have this Authenticate?
I'm just getting started on figuring out the CyberSource Flex Micro Form code out myself and it's pretty straight forward from what I can see. If you don't have the proper SDK already pulled in, you can fetch it from https://github.com/CyberSource
I had to use Composer to fetch all the dependencies but once I did, I was able to load up the microform checkout page in my browser window successfully. Make sure you edit the ExternalConfiguration file with your credentials that you setup in CyberSource.
The apiKeyId value is the value you can find in your CyberSource account under Key Management. This is the value with the dashes in it.
The secretKey value is the value you should have downloaded from CyberSource that is your public key. This is the value without the dashes and probably has a few slashes / in it.
That's all I had to do in my setup to get the first successful authentication / token on my end.
I'm sorry in advance if something bring you here and I talk about a platform that's not really well-known over the world despite featuring a well-known person dancing in their commercial.
It's Shopee Open Platform API I talk about. I was trying to follow very properly their instruction here.
https://open.shopee.com/documents?module=63&type=2&id=51
But stuck instantly at step 5 : Shop Authorization. First, I've been given a test partner id, a test key, and I need to set manually the test redirect URL. I have to generate authorization token from all given information. Firstly I need to create a token base string by concatenating the test key with URI component encoded string of the URL. It turns into something like this.
9b754aca01a5d719cb70c5778294dae6ff90fcc68c82908ee480a36ff901d181https%3A%2F%2Fwww.unwelldocumented.com
To generate the authorization token, it says I need to do hexencode(sha256(token_base_string)). It returned a very long integer.
32373935663639356636346266303137613465396239383361373334646133656530313333393762636138396364663037366566313366313436316534303761
So I just assumed everything is fine and that is the authorization token. But when I send this...
https://partner.uat.shopeemobile.com/api/v1/shop/auth_partner?id=(test_partner_id)&token=(authorization_token)&redirect=(test_redirect_URL)
... suddenly I get this
{
"error": "error_auth",
"msg": "Invalid token",
"request_id": "30a4b6b0074541bdd88260a33f155ca6"
}
In order to solve this, you have to understand that SHA256 is an Encryption hash function. Please research more on SHA256 on your specific language.
For this very specific case, your SHA256 token should be as below.
Before SHA256:
9b754aca01a5d719cb70c5778294dae6ff90fcc68c82908ee480a36ff901d181https%3A%2F%2Fwww.unwelldocumented.com
After SHA256:
2795f695f64bf017a4e9b983a734da3ee013397bca89cdf076ef13f1461e407a
The rest of your steps seems correct.
I am trying to verify a HS256 JWT Token generated with locally ran KeyCloak Authentication Provider on https://jwt.io.
The KeyCloack instance is running on my local machine inside a docker container. I have applied almost the same steps as described in this answer (which on contrary applies the RS algorithm instead, and works as described): https://stackoverflow.com/a/55002225/1534753
My validation procedure is very simple:
1.) Request the token (with Postman) from my local docker KeyCloak instance with:
POST requesting http://localhost:8080/auth/realms/dev/protocol/openid-connect/token
2.) Copy the token contents inside the jwt.io's "Encoded" section
3.) I verify that the header and payload are as expected and correct
4.) I copy the client secret from my KeyCloak instance admin dashboard, you can see the reference on the image below:
5.) I paste the secret into the "VERIFY SIGNATURE" section on jwt.io and the "Encoded" token section changes, hence resulting with an invalid signature and a invalid (i.e. different) token.
My core question is what am I missing here? Why does the token change when I apply the expected secret!? Am I applying the right secret, the one from the client? If I understand JWT infrastructre and standard correctly then It should stay the same if the secret (with the expected algorithm applied) is valid. My reasoning is that something with JWT creation on KeyCloak is specific. I have not touched the HS256 algorithm provider on KeyCloak, everything is used as default with the docker installation guide on using KeyCloak. The settings related to the token and algorithm are setup to use HS256, and the algorithm is specified as expected in the JWT's header section correctly which can be verified after the encoded token is pasted into the jwt.io's page.
I need this to work as I am trying to apply the same JWT validation process inside a .NET Core web API application. I have encountered this whole issue in there, i.e. inside the System.IdentityModel.Tokens.JWT and the JwtSecurityTokenHandle.ValidateSignature method which results with an invalid signature and finally resulting in an exception.
On side note, I am accessing the token with Postman and its Authorize feature the configuration can be seen on the image below:
One more side note is I have a user "John" which belongs to my "Demo" realm. I use him to request an access token from KeyCloak.
To get the secret used for signing/verifying HS256 tokens, try using the following SQL:
SELECT value FROM component_config CC INNER JOIN component C ON(CC.component_id = C.id) WHERE C.realm_id = '<realm-id-here>' and provider_id = 'hmac-generated' AND CC.name = 'secret';
If you use the resulting secret to verify the tokens, the signature should match. I’m not sure if this secret is available through the UI, probably not.
Source: https://keycloak.discourse.group/t/invalid-signature-with-hs256-token/3228/3
you can try using Keycloak Gatekeeper.
If you want to verify that token in that way you need to change the Client Authenticator to "Signed JWT with client secret", otherwise you can use this "Gatekeeper" option. Here you can read more about it.
We have an instance of Identity Server 3 which has been used for some time with various clients, some using implicit flow, others using client credentials. We now have a new requirement to integrate an iOS native app with this identity provider. I understand these days implicit flow is not recommended and public facing apps should instead be using authorization code flow. Examples of such advice are here and here.
By my understanding, authorization code flow has a step whereby a received authorization code is exchanged for JWT tokens via some back channel by supplying it alongside a client ID and secret. However, with SPAs and native apps we don't have the luxury of storing secrets. The guidance I found here would suggest I can simply omit the secret from the connect/token request, but my testing so far doesn't confirm this. So I'm stuck. To demonstrate, I've set up a client on my local instance of IS3 to test with:
{
'clientId': 'test',
'flow': 'AuthorizationCode',
'name': 'test',
'redirectUris': [ 'http://localhost:8080/' ],
'scopes': ['openid','profile']
}
I then make the following GET request to my IdP:
[ID_PROVIDER]/connect/authorize?client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080&scope=openid%20profile&response_type=code
This lets me sign in and returns me to my test app running at http://localhost:8080 with my authorization code in the querystring.
I now try to exchange this code for JWT tokens by POSTing to [ID_PROVIDER]/connect/token with the following body: code=[AUTH_CODE]&grant_type=authorization_code&client_id=test&redirect_uri=http%3A%2F%2Flocalhost%3A8080
But Identity Server rejects this with an HTTP 400 and invalid_client error. When I dig into its logs I see a ClientSecretValidator event with message "No client secret found". Which kind of makes sense based on my understanding outlined above, but given people are recommending using this flow for public-facing apps I must be misunderstanding something.
If anyone could clarify that'd be great, thanks.
You can't just omit the client secret. For your native case, I'd consider embedding the secret within the app. The authorize request will still have to validate the return_uri (custom URI scheme for your native app) and if that still feels insecure, you can also lean on Proof of possession (PoP) tokens (https://identityserver.github.io/Documentation/docsv2/pop/overview.html).
For a SPA app I would keep it implicit flow, I see no point in doing secrets there.
I need to access a private data set in socrata using SODA API. Suppose below link is the data set
https://data.cityofchicago.org/resource/xxxx-xxx.json
I get the following error when try this.
"error" : true,
"message" : "You must be logged in to access this resource"
I have valid credentials to access the data set. But how can I pass it through SODA API calls?
I tried the below code but it doesn't work.
https://data.cityofchicago.org/resource/xxxx-xxx.json?$username='myname'&$password='pwd#123'
You'll need to use either HTTP Basic or OAuth 2.0 to authenticate. We have details on how to do that on the developer portal.
Make sure you also provide an application token, as detailed in those docs.
You need to pass Secret-Token and AppToken with the query string.
How to Get secret Token
Log in to your portal and select "Create new Application"
Enter https://data.cityofchicago.org/resource/xxxx-xxx.json in the "website" field.
Save it.
Go to "Manage" and get your AppToken and SecretToken from under "Manage".
Now, pass the app token and secret token in the URL according to socrata developer document syntax:
https://sandbox.socrata.com/oauth/access_token
?client_id=YOUR_AUTH_TOKEN
&client_secret=YOUR_SECRET_TOKEN
&grant_type=authorization_code
&redirect_uri=YOUR_REDIRECT_URI
&code=CODE
I am also looking for an answer for the same question. After passing the app token I can access public DB but can not access Private DB.