I have seen the demo in WWDC18 related video here:
https://developer.apple.com/videos/play/wwdc2018/303/
but it is not from the scratch. I don't see that which tool they have used and where we need to start it. Can anyone help with it?
I watched that video too today and I wanted to use these API features, as for now 19-6-2018 this is still marked as coming soon... based on the App Store Connect website https://developer.apple.com/app-store-connect/
In addition, the new API Keys tab under the main App Store Connect is not available yet.This is the starting point to issue / create the API keys.
I am on look out and waiting...
The App Store Connect API is now available. You can find out more here:
https://developer.apple.com/app-store-connect/api/
The general steps are:
Request access to the API.
Your Team Agent (with the Legal role) will need to do this part.
Create and download an API key.
Anyone with Admin access can do this. Each key you create can only be downloaded once, and should be kept safe.
Use the information on the Keys tab + your private key to generate a token.
You can find libraries for many languages to make this easy here.
Supply the JWT as a bearer token in the HTTP Authorization header when making requests.
For example:
GET https://api.appstoreconnect.apple.com/v1/apps
Authorization: Bearer XYZ123
Where XYZ123 is your JWT. (Your real JWT will be much longer.)
Available API endpoints are documented here:
https://developer.apple.com/documentation/appstoreconnectapi
App Store Connect API available here now.
Related
I am facing the challenge to request the Bing Ads API to get a couple of metrics from it.
I am using Apache Airflow DAGs hosted on a remote Kubernetes cluster to do so. It is a nice way to automate and schedule tasks.
Now, the documentation is rather light on the point of gaining access to the API.
I have followed this https://learn.microsoft.com/en-us/advertising/guides/authentication-oauth-identity-platform?view=bingads-13#registerapplication
and the official SDK docs https://github.com/BingAds/BingAds-Python-SDK/.
I am failing at authenticating when querying, since I am lacking a couple of pieces of information.
When authenticating using the "refresh token" and "redirect URI", I do not have either. (Class OAuthWebAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L566)
When using a different method (Class OAuthDesktopMobileAuthCodeGrant here: https://github.com/BingAds/BingAds-Python-SDK/blob/294d01eea57d80ba381a42cde8d006fc318af056/bingads/authorization.py#L532), I fail w/
AADSTS700016: Application with identifier '<someidentifier>' was not found in the directory '<somethingelse>'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.
Thank you very much in advance! If you need more details, let me know!
Also great documentation in general, if I can make it more "newb"-friendly, let me know!
Edit1:
Sadly, while there has been some traffic to this question, nobody seems to be able to answer.
I will specify the set up a bit further.
We use Airflow DAGs to request daily updates from the API. For this, we need to authenticate. The authentication comes from a "new device" every time, since the code runs on a k8s cluster which allocates the jobs dynamically to it's pods.
For authentication, we ventured into different solutions, but all require some form of human interaction to get the refresh token into the DAG.
Is there any solution which allows for a hands-free deamon like many-server-to-server communication?
This link sheds some light on what we are looking for: https://learn.microsoft.com/en-us/azure/active-directory/develop/scenario-daemon-app-registration#api-permissions---app-permissions-and-admin-consent
Sadly, the Bing Ads API does not show up there.
What key piece of information are we missing?
Bing Ads, like Google Ads, uses OAuth for its API.
If you reference the Getting Started page, it mentions that you need a developer token, complete with links.
You can follow these steps to get a developer token for production.
Sign in with Super Admin credentials at the Microsoft Advertising Developer Portal account tab.
Choose the user that you want associated with the developer token. Typically an application only needs one universal token regardless how many users will be supported.
Click on the Request Token button.
Regarding your specific scenario--an application running in the cloud without an interface--you should know that OAuth requires you to interact with it to set things up. So run your app locally ONCE, or at least the getting_started code from your language's walkthrough: https://learn.microsoft.com/en-us/advertising/guides/walkthrough-desktop-application-python?view=bingads-13
Running it locally will go through the authentication process with your browser and generate a refresh token (in the file refresh.txt by default). Store this file with your code. It will have to be on the server that's making the request, and since it's in Kubernetes, you'll have to keep it with your container file.
Can someone please tell me which of this architectures is stateful/stateless?
REST API with session user authentication stored on redis.
REST API with JWT user authentication stored with revocation list on redis.
REST API with oauth2 user authentication.
I would like to also know if I can have resource and authorization server as one and the same API in terms of oauth2. Is it worth to have own authorization server?
What kind of user authentication and app authentication would be easy and secure to use as start up for REST API that will be used by the website and mobile app? I understand it would be 2 authentications one for user and one for app.
Please this is for me more like wrap up of all stuff I've read so I just need short answers - already had a lot of reading.
The key goal is to externalise it - your UI and API code is then simple and stateless. This is what an Authorization Server enables.
The AS is something you interface with and configure - but you don't code it yourself.
Use a free / cheap Authorization Server from a cloud provider like Google or AWS
Following the OAuth 2.0 and Open Id Connect standards is the lowest cost option if you make the right choices - though there is a learning curve.
As an example my Cloud Samples are pretty much zero cost to me - and my code is simple - even though anyone on the internet can run them.
In terms of getting connected, maybe have a browse of my first tutorial.
I was able to make a google api based Oauth 2.0 authorization module, which seems to work. I had to create an google cloud platform app to get the client id and client secret and register the uris. Now the new requirement is that we need other login options like facebook, stack exchange, etc options.
Now the question is that should I have to register my app with Facebook and stack exchange as well to obtain different client ids and secrets? Is there a generic way ? thank you.
Now the question is that should I have to register my app with Facebook and stack exchange as well to obtain different client ids and secrets?
Yes, of course, you'll have to. An app/client id and secret are integral part of those APIs and their login mechanism. They are not somehow interchangeable between platforms.
Plus, while following the OAuth standard more or less, they all have small difference in their APIs - different endpoints for certain tasks, differently named parameters and permissions, etc. There's a chance that you might be able to re-use code on some level - but you will have to branch out to handle each platform in its own way at some point or other.
I am implementing espn api, but having some issue, most api gives me this response.
{"timestamp" :"2013-02-25T11:19:02Z","message" :"This action is forbidden for the requested resource at your permission level. Please review the documentation for account level access.","status" :"error","code" :403}
I am using this api Espn MLB Standing
I want to know that where to review the documentation, i is there any need to purchase some api or anything else?
[EDIT]
One more thing there is ?apikey=:yourkey , so this key is same for all user or we have to get this according to user login.
I think you are using the wrong apikey or there is some issue in your URL query.
Your app will have a unique apikey. This key is same for all users who are using the app.
You should get a apikey by registering to their site and use it for development purpose.
My rep doesn't allowing commenting, but I thought I'd add the following here:
A small amount of ESPN API data is free, but much requires payment.
You probably don't want to publicly share your personal API key for security reasons.
Go to http://developer.espn.com/io-docs and plug in your API key and use the GUI to generate an API call/response. It's a good way to see a valid, working syntax that you can then drop into your app and edit as necessary.
We intend to develop rest based api. I explored the topic but it seems, you can secure api when your client is an app (So there are many ways, public key - private key etc). What about websites / mobile website, if we are accessing rest based api in website which do not use any login for accessing contents ( login would be optional ) then how could we restrict other people from accessing rest based api ?
Does it make sense using Oauth2.0 ? I don't have clear idea of that.
More clear question could be ,How can we secure get or post request exposed over web for the website which doesn't use any login ?
If it's simple get request or post request , which will return you json data on specific input, now i have mobile website , who will access those data using get request or post request to fetch data. Well, some else can also access it , problem is i am not using Login, user can access data directly. But how can we restrict other people from accessing that data.
What do you think is the difference between securing a website that is not using REST vs one that is using REST API?
OAuth provides authorisation capabilities for your site, in a REST architecture this means a user of the mobile application will have to provide their credentials before being allowed to access the resource. The application can then decide on if that user has access to the requested resource. However you've said your website doesn't need use authorisation.
You can use certificates however good luck managing the certificate for each client. My take on it is for your explanation you don't need to secure your website because you will never be able to manage a trust relationship between the client and the server. There are some options though:
You build your own client application that you ship out to people which can verify itself with the server using a packaged certificate with the client. E.g. iOS has this kind of feature if you build for that device.
You provide a capability to download a certificate that is 'installed' in the browser and used when communicating to your REST API
Use something like a handshaking protocol so when a client wants to make the first request it says; 'hi I'm a client can we chat?' And the server responds with 'yes for the next X minutes we can however make sure you send me this key everytime you tell me something YYYYYY' (you can use something like SecureUDID or equivalent for other devices than iOS).
There are probably others but you get the basic idea. Again in my opinion if your resource doesn't need authorisation then you don't need to secure that REST API. Can I ask what kind of data are you exposing via this REST API or functionality your providing? That might help provide a better answer.
You want authorization: only some agents (mobile clients) and/or users should be allowed to access those APIs.
To solve that problem, you need identification: a way for the server to tell who is who (or what), so the right decision can be made.
There are many different way to provide some form of identification, depending how much you care about security.
The simplest is a user agent string, specific to your mobile clients. But it can be faked easily. Slightly harder to fake are client based 'secrets' - embed some kind of secret or key in your mobile client code. You can make it really complicated and secret, but as ramsinb pointed out, you can't get security this way as it would require you to be able to guarantee that the secret you're shipping with the client (wether it's code, algorithm or any other fancy construct) can't be compromised or reverse engineered. Not happening when you don't control the client.
From there, 3 choices:
Security isn't really required, don't bother
Security isn't really required, but you still want to limit access to your API to either legit users/agents or people ready to invest some time hacking your protection - go with a specific user agent or a client embedded secret - don't invest much into it as it won't block people who really want access to get it anyway
Security IS required - and then I don't think there is a way around authentication, wether it's login/password, user specific (device specific?) keys, OpenID, etc... No matter what, you'll have to add to the user burden to some extent, although you can limit that burden by allowing authentication to persist (cookies, storage....)