I have a website that takes card payments using Stripe. Currently it uses the checkout API, but I am upgrading it to use the SCA API, and PaymentIntents.
I am concerned however that it appears that the PaymentIntents API requires you to present your secret key in order to create the session.
As I don't have my own servers, and am using hosted environments, I don't really want to place a secret key on these.
Indeed Stripe themselves say "Secret API keys should be kept confidential and only stored on your own servers. Your account’s secret API key can perform any API request to Stripe without restriction."
I have engaged with Stripe support, and they appear to be saying that yes, you can't use a restricted key, you have to use the secret key, but I don't like this!
Am I missing something, or going about it the wrong way? Has anyone got PaymentIntents working without the secret key?
Related
I'm building a "multiplatform" solution where each user could have it's "shop" and receive the founds directly on their stripe accounts.
So each user when creates it's shop provides public and secret stripe key which are stored on the server and used when some payments are made.
The problem comes when i have to use the webhooks where i have to verify the user webhook endpoint secret, i can't ask the users to provide and store the WH endpoint key...
(I use the webhook to send the order in preparation once the payment charge is succeeded)
So i was wondering if there was a way to manually verify the webhook signature without using the endpoint secret, i saw that here is possible manually verify signature but anyway i have to use the endpoint’s signing secret as key..
It's not possible to verify Stripe webhook event payloads without a webhook signing secret.
However, it sounds like your use case fits Connect quite well, and a Connect webhook endpoint may work for your needs.
Connect webhooks will receive events from all connected accounts, and will avoid the need to manage individual webhook endpoints and secrets for each account.
Our scenario is that we have an API which is currently only secured by a subscription key in APIM.
We plan to change this to also secure it with OAuth 2 following this guidance from Microsoft, we will then use the JWT validation policies within APIM to ensure that the user requesting access is a member of the appropriate groups to access given endpoints etc.
However as part of our release process we need to run some automated tests which call the API and check that certain data is returned.
Because these tests are run as part of an automated release pipeline we are struggling to understand how OAuth will fit into this process - as a user is required to enter credentials for a token to be issued...
We originally thought that we could just request a token manually once and then hard code it into the tests, but as tokens are only valid for a short time this isn't a good solution.
Other things we are considering are :
Creating a "test user" in AD and storing their credentials in the test project and then when the tests run we can request a token using the "Password" grant type and passing the username and password" however this doesn't seem like the best from a security point of view, even though the user would only have access to a very limited subset of the APIs functionality it still doesn't seem like a good practice.
Requesting a token using the client secret, however the downside to that is this is that the JWT does not contain the groups claim so this token will not pass JWT Validation.
This must be something that others have encountered? What is best practice in this scenario?
As you can see in the article you reference, you will be using Azure API Management to be the entry point to access your API. So, using the API Management you will have subscriptions with keys for your API. You just need to create a subscription for your automated testing, and save the key in the Azure Key Vault. And then during the deployment, you pull your subscription key from your Key Vault, and use it to call the API Management Endpoint, that consequently will call your API.
The solution that we went with in the end was to create a new App Registration for the Test project, then in APIM we added a rule so that the JWT policy is not applied to connections from that app.
Might not be the best solution but it works.
I'm developing a chrome extension using maps API which autofills the address in the address fields of the current page. For testing purpose, I'm currently using my own API key. But I see using this API key I can hit only 25000 requests per day. So I thought of using the user's API key, whoever uses this extension. Using OAuth, I can get the user's consent for accessing his information but can I get his API key and use it that way? I have set up a server so that I can store the user's API key to be used again. Also for the user' consent, I use my API key and client id. Is it possible?
We have a situation where our users will be logging into Paypal and then paying other people from their Paypal account via our dashboard. We have the connection setup to retrieve refresh & authTokens for them via simple-oauth2 module. What I don't see is how to utilize a token in the Paypal Node SDK. It seems to only support client id and secret configurations.
Is there a way to utilize the paypal.configuration with an authToken instead?
Should we be using the REST APIs directly instead of the SDK?
You cannot directly transfer amount to other people account.
You firstly need to transact it into your own buisness account and then you can transfer it to any other person account.
I'm using the express-stormpath package with a new application I've created in my account at Stormpath.com.
I use stormpath in my app I have to provide an application HREF provided in the application page in the stormpath admin, I also have to provide a API Key and Secret.
I've been creating a new API key/secret for every app I've made on the one admin tenant assigned to the account, the one I signed up with.
And I use that API key/secret to authorize my express application with Stormpath.
So in my admin account I have a long list of API Keys and I have no idea which key is for which app.
Is this how I should be doing it?
It just feels very messy. I see that normal application users can be given API keys/secrets, what are these for? Can I create an admin users for each app and use their API keys and secrets without making them a stormpath administrator?
Does that make sense? I've tried emailing the support directly.. but they didn't really understand any of this. :/
First of all, this is a great question, so I’m not sure why you’re being down voted. API keys can be a confusing topic. I’ll try to clear up the mystery around them before answering your specific questions.
In Stormpath, there’s two types of API keys: Tenant API keys, and Account API keys. Tenant API keys are what you need in order to make API calls to Stormpath. They identify you as an administrator of your Stormpath Tenant, and give you full read/write access to all of your Tenant’s data (in other words, anything and everything you’ve stored in Stormpath). By definition, an administrator has access to the Stormpath API and the Admin Console (aka the webpage you see when you log into Stormpath).
There’s also the notion of Account API keys. Accounts are people (or devices) that are signing up to use your web app, mobile app, or API service. In Stormpath, Accounts are stored in Directories, which in turn are stored in Applications. You can read all about this here. I like to think of Account API keys as a more secure version of a username and password. They’re really useful if you’re building out your own API service and want users to authenticate before they start making requests to your API.
That’s really all there is to it. API keys authenticate you — nothing more, nothing less. There’s tons of articles out there debating whether or not API keys are more secure than other methods, so you’re free to check those out. But in Stormpath, in order to communicate with our API, you must identify yourself as a Stormpath Tenant administrator. As you build out your own web app, mobile app, or API service, you can choose how you want your users to interact with your services.
I hope this helps clear things up.
If you want to create any other type of roles/permissions for your users, you’ll need to learn about authorization and how it works in Stormpath. I won’t elaborate on that here, but you can read all about it in our docs.