I want to integrate Private Identity authentication into my web app, at the HTML level. How do I do that? Where do I find the iframe code and how do I get an API key?
If you want to integrate private identity into your web app, you can get the iframe code from https://github.com/openinfer/PrivateIdentity/wiki/DIV-HTML and for API key you need to go to AWS Marketplace and subscribe to Private Identity then you will get the API key Another way you can contact to support#private.id
Related
I have an enpoint in my MERN app which I would like to expose to developers.
I came across APIM and would like to use it.
After going to the documentation I would like to know how do I can use APIM for my specific enpoint and where I allow users to generate API's in my client side react app.
I am also going through the API management API. but don't know how to generate user specific API keys...
You could simply mimic what the Developer Portal does using APIMs REST API.
If you are using the Consumption Tier of APIM, you can just create a standalone subscription using the Create or Update Subscription API. Yon don't have to set properties.ownerId in the request payload here.
On the other tiers, standalone subscriptions are not supported yet (but will be as mentioned in the official announcement blog under New Features), so you will have to create a user first using the Create or Update User API and then create a new subscription mentioning this user under properties.ownerId as /users/{userId}.
Since these REST APIs call the Azure Management API, you shouldn't be making these requests from the client and instead should be calling this from your backend.
i tried to set up a simple map: http://pan-american.ch and keep getting the same error in the JS Console:
https://developers.google.com/maps/documentation/javascript/error-messages#referer-not-allowed-map-error
Your site URL to be authorized:
on this Domain http://map2.codedesign.ch the key works fine.
so my question is - where can i add Domains...
You want to setup the referrers to allow http://pan-american.ch.
See the Google Documentation on Setting up API keys:
Setting up API keys
If your client application does not use OAuth 2.0, then it must include an API key when it calls an API that's enabled within a Google Cloud Platform project. The application passes this key into all API requests as a key=API_key parameter.
To create your application's API key:
Go to the Cloud Platform Console.
From the projects list, select a project or create a new one.
If the API Manager page isn't already open, open the menu Gallery Menu and select API Manager.
On the left, choose Credentials.
Click Create credentials and then select API key.
Choose the type of key to use. (API key types are described in more detail in the following sections.) If you're unsure whether an API key is appropriate for the API you're calling, select Help me choose and follow the instructions to pick the right credentials.
Note: In addition to reading the instructions on this page, be sure to read Best practices for securely using API keys.
The API supports several types of API keys, including server keys, browser keys, iOS keys, and Android keys.
Browser keys
Create and use a Browser key if your application runs on a client, such as a web browser. To prevent your key from being used on unauthorized sites, only allow referrals from domains you administer.
I am trying to make a call using the Google Container Engine API via my browser. I have created both a client ID and the public API access key.
When I try to use the public API access key, I always get unuauthorized:
https://www.googleapis.com/container/v1beta1/projects/cohesive-feat-92204/clusters?fields=clusters%2FmasterAuth&key=XXXXXXXXXXXXXXX
(where XXXXX... is my key)
Is there a document that describes all the required values for the call? How you specify the client ID and the client secret etc...where you put in the scope, etc...
This link https://cloud.google.com/container-engine/docs/v1beta1/libraries gives me a 404
This is the same question as Google Container Engine REST API Authorization and the answer is that a public API access key cannot be used to access the Google Container Engine API.
How can we prevent a public API to reveal master API keys/credentials and secret tokens?
I am currently working on a webapp with some public API which should use API keys and secret tokens and were looking for a way to create a very secure API and took some look at some of the APIs of the biggest platforms, for example SoundCloud.
I read some guides (like https://github.com/interagent/http-api-design) about good (restful) API design, but they give not much information about the security (API keys and tokens) and how they should be retrieved or created in public APIs.
Take a look at https://a-v2.sndcdn.com/assets/sc-q9dV-e79e4b4a.js and search for b45b1aa10f1ac2941910a7f0d10f8e28
This is the master API key of SoundCloud.
Some of their URLs look like this:
https://api.soundcloud.com/tracks/id/stream?client_id=client_id
https://api.soundcloud.com/tracks/id/stream?secret_token=secret_token&client_id=client_id
https://api.soundcloud.com/playlists/playlist_id/?secret_token=secret_token&client_id=client_id
I know that many tools out there are already using this key for fetching/downloading all the songs from a SoundCloud user.
Also all their private and secret widgets reveal the secret tokens, also in the requests and in the sourcecode. They are hardcoded in the JavaScript code of the embed codes.
The problem consists for some years and the developers seem to have no experience with secure APIs
http://tunelab.com/2011/08/04/this-is-the-problem-with-soundcloud/
How can such APIs using JavaScript and JSON prevent to reveal these tokens and credentials?
My thoughts about this:
the master API key should be only accessible through/from soundcloud.com
there should be some sort of domain/IP blocking/restriction//firewall for all API keys
use OAUTH for all API keys, not just a simple JSON API with no authentication
dynamically generate one-time (secret) tokens, do not reuse the same token all the time dynamically get the API keys and tokens from the SoundCloud server instead of putting them into the embed codes and requests use some sort of steganography
When I read that SoundCloud is the biggest music community and big music labels upload their songs from new or upcoming albums (even as private songs and post them with a widget on websites, the secret tokens are also revealed) it seems, that the team behind SoundCloud does not want to protect their users against piracy/stealing of songs and is not willing to create a secure API.
What do you think about this critical situation on soundcloud.com and how could a JavaScript/JSON API be much more secure/secured the right way without revealing any critical data like tokens and API keys? For example using AJAX and retrieving the API key and token after the website is loaded?
How do Spotify and other streaming platforms protect the data which they are streaming and get the token and API key? Is storing these information in a URL or request URL secure at all?
How can I securely send the API key and secret token to my users over the wire using JavaScript, HTML, AJAX and PHP?
how do I deliver the API keys and secret tokens securely over the wire to the users?
There is only one reliable way: use HTTPs for your web site to allow the users to retrieve the key.
Then during the API calls HTTPS is no longer required. Your users can use HMAC authentication to hash the key with a shared secret.
I'm planning on doing a uniform JSON REST API for both my javascript based web app and as an API for other developers to use.
What I would like to do, is have my js app authenticate users using a username/password and allow them to access their own private resources. When the API is going to be accessed by other dev's, I'd like to allow them to access public resources (while still being able to track their API usage) and also let them access user's private data with the users permission (authorization ?).
Now, how would I go building such an API? What libraries/protocols/... would be the best at this?
Thanks.
You should really check out Oauth. Take a look at http://oauth.net