Oauth2 authentication for installed applications using service account flow - google-oauth

I've successfully built a ruby script and a mac app that use service account credentials to authenticate (without user interaction) to google cloud storage and upload/download objects.
I now need to perform similar actions on an iOS device. Is it possible to use installed application credentials to authenticate still without user interaction?
If it's possible or has been done, can you please provide an example or point me in the right direction.
Thanks!

You need the private key for the service account to get the access token for the application. Please bear in mind that some hacker may steal that private key for both mac and iOS app. If the data is per user and you have a backend server, you may authenticate the user on the backend and then use the private key on the server to access the storage. If the data is per app, seems there is no good way to prevent the private key abuse.

Related

Can multiple Android Applications(same device) share same key-pair for Passwordless Authentication using FIDO 2 Protocol?

Problem Statement:
I want to solve the user authentication on Android applications using the FIDO2 protocol(by providing an SDK), without doing multiple registration ceremonies for different applications on the same device.
For example, If a user has been Registered(generated Public-Private key pair) in an Android application A, he/she shall not be required to Registered in an Android application B(Given App A and App B are on the same device).
What could be the possible Solutions(as per my knowledge):-
A common SDK integrated with application A and B to provide authentication.
Separate Authentication App.
I want to go forward with Solution 1 as Solution 2 might not be desirable because it needs an extra step of downloading an extra app(Authentication App).
What am I able to achieve right now:-
We are able to do passwordless authentication of a user for app A and app B by maintaining separate private keys for app A and app B .
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
During the registration step a Public-private key pair is generated by the authenticator.
PrivateKey_1(PrivateKey) gets created and is stored in the Keystore and PublicKey_1(PublicKey) gets created and is shared with the server.
Let's say now that User XYZ wants to login to the app B.
Same process gets repeated for user XYZ to register him with app B.
In this process, A PrivateKey_2 gets created and is stored in the Keystore and PublicKey_2 gets created and is shared with the server.
So in above scenario User XYZ is able to authenticate on App A and App B using private key PrivateKey_1 and PrivateKey_2 respectively.
I want to know the feasibility of the following Scenario?
I want to do passwordless authentication of user XYZ for app A and app B, where applications(app A and app B) can use the same credentials (public and private key pair ) and do not need to perform a repeated registration ceremony(creating public and private key) for the same user on the same device for multiple applications sharing the common SDK(app A and app B).
In the above diagram:-
User XYZ logs-in to App A and registers himself with app A on this device.
In this process, a PrivateKey_1 gets created and is stored in the Keystore and
PublicKey_1 gets created and is shared with the server.
User XYZ wants to login to the app B.
App B should be able to verify user XYZ using the previously generated
credentials(by app A).
Is this even possible? Is there any gap in my understanding?
Any Suggestion and help is really appreciable :) :)
FIDO2 credentials can be reused wherever the API is available so long as you reference the same RP ID whenever you attempt authentication. FIDO credentials are bound to a unique RP ID, and as long as you can prove ownership of an RP ID then you'll be able to request authentication with any credentials associated to that same RP ID.
In the case of Android, you'll be able to auth across apps so long as both apps are connected to a single website and its unique RP ID. To connect your app to a website, check out the FIDO2 API for Android docs, particularly its section on Interoperability with your website. It links to Google's page for setting up Digital Asset Links on your site so that you can prove ownership of an RP ID and use credentials associated with it for authentication across apps.
Once your apps and website are linked and the user has registered in one app you should then be able to use Fido2ApiClient.getSignPendingIntent() to authenticate in your second app so long as you specify your site's RP ID (the same one specified during registration) as the rpId in the PublicKeyCredentialRequestOptions you pass to the method.
P.S. What's nice about all of this is that credentials you register using Fido2ApiClient (or any equivalent API on other platforms for that matter) in a native app can later be used to log into your website using the WebAuthn API in the browser; you just need to reference the same RP ID in the PublicKeyCredentialRequestOptions you pass to WebAuthn's navigator.credentials.get()!
One of the main benefits of FIDO2 is that it prevents man-in-the-middle attacks where an attacker is trying to impersonate a genuine replying party. The FIDO2 key will only respond to the RP for which the private key is registered. Sharing authn across multiple RPs would break this model. I don't know what is possible on an Android device but I would have thought you would need some form of authentication broker (an IdP) which you auth to with the Key and it is responsible for proving auth to the apps.
Are these accounts registered on the same service? Reading the Android FIDO2 API Interoperability with your website section, it seems possible to host https://example.com/.well-known/assetlinks.json with multiple Android apps listed.
I saw your problem statement and I think you should use SAWO Labs API for solving the authentication part as it is very easy to use. You can use one API key in multiple applications to use the authentication and also this API has a trust feature where you have to authenticate from each application where the same API is used for one time and you will no longer need authentication every time. SAWO Labs API is a passwordless user authentication tool.
You can know more about the SAWO Labs API from the link given below:
https://sawolabs.com/

Authenticating Xamarin Forms app with Azure Active Directory for accessing a protected Azure AAD Web API app

Not sure how to go about doing this; I'm not looking for B2C, I don't want my users to sign in. I just want my Xamarin app to be able to access an Azure AAD protected API. In other words, I want to authenticate the app itself with the Azure Active Directory, to access an Azure AAD protected API. From what I've found on the internets, service principal to service principal auth is discouraged when using mobile apps and I've not really found a way to do it service to service anyhow.
Any suggestions on how to properly do this? Links with tutorials would be great.
Thanks!
Azure does provide the ability to generate a client ID which you could have sent from your application and checked. Microsoft talk about this in this article. You will want to be careful with how you store this ID in your app as if someone were to steal this they would be able to access your API. Along with that you'd also want to make sure that your connection between your app and server is secured with a pinned SSL certificate so it cannot be man-in-the-middle'd.
Another interesting approach is software attestation where some service checks various aspects of your app to ensure that it is your app. Full disclosure, I work for a company which does this. See Approov. We take a fingerprint of your app and our SAAS checks that this matches at run time. We then issue a token which your app can use to prove that it is the real app.

Accessing iCloud securely on behalf of user (server to server)

Are there step by step instructions anywhere on how to generate a "ticket" for an iCloud user given their username/password. I'd like to build a service that access iCloud data (server to server) without having to store the iCloud username or password.
My understanding is that you use the username/password to generate a Kerberos ticket from iCloud. That's based on the answer to How does Sunrise for iOS use iCloud credentials to access our calendar? . But I haven't found instructions online on how to do that.
Does anyone know how to do that? Thanks!
Let me start by pointing out that by default iCloud app storage is "sandboxed" in containers. A signed application can only access its own container without having the API key to authenticate to other application containers. You can make multiple applications share the same container, or use multiple containers in the same application if needed, but essentially you have to be the developer of all applications or have explicit permission to do this. Check out Incorporating iCloud into your app and Enabling CloudKit for more details.
Other (non-appstore) applications and services can authenticate to use an application's data via CloudKit Web Services:
Authenticating to iCloud (redirect based, so credentials still are never revealed and are known only by the user and iCloud server itself);
Further authenticating with your application API key;
The process is described in detail here, as already kindly pointed out by Adam Taylor.
All the above being said, If I understand correctly, you want to have access to all of the user's iCloud data. I think, you won't be able to do so for multiple reasons:
Data is protected by application key, so you need to have this to access a container in addition to the basic credentials;
I'm sure that Apple has a design policy to never ask for user credentials in plain text. Asking the user explicitly for credentials will be against their policy and even if it turns out it is not, having the credentials won't help you much, because you have to enter/send them somewhere. But all iCloud authentication mechanisms are designed to ask for authentication only by the end-user.
This is why I don't believe it is possible to just use user credentials and get access to all of their iCloud data. Now, my 2 cents on why Sunrise works:
As far as I understand, the Sunrise application works, because the calendar data is designed to be shared via CalDav, that works on a concrete URL, so you can import and link your calendar in various calendar client applications. The URL can be found out with a bit of investigation. CalDAV is kind of similar to IMAP and POP3 for mailbox access.
Be so kind to elaborate a bit more on what kind of data you're trying to extract (apple application specific, developer application specific, documents, key-value pairs or something else) and me or other users might help you further.

Can I use Oauth to authenticate a Shopify private app?

How can I use Oauth to provide authentication for my private app?
I understand it's not necessary to make the actual calls, but I want to know about protecting the whole app in a way which my client doesn't need to log in twice.
If this is not possible, how do people manage their private apps?
Question is not clear
but, Here is some info
Oauth is an autherization Flow(Protocol) for end-users to authorize third-party access to their server resources without sharing their credentials(Ie. User Name and or password).
If your app is like third-party app that request user resources(ie. email or other details) from Resource servers(ie. Google , Facebook) Then Oauth is the Fittest solution.
Keep the session cookies (access Token) for avoid log in twice.

Authenticating against a realtime-server used in a Symfony2 project

I recently started a new project using different carefully-chosen technologies, my project is built as follow :
The approach is API-Centric, which means I'm building a website and an iOS app communicating with an API written using Symfony2. I've successfully managed to write my API, and it is perfectly working.
To gain access to the services provided by the API, the main actors (the website users, the iOS app users and the developers) can authenticate theirself in several ways :
Clients can gain access with a login/password couple through the website interface which is communicating directly with the API through AJAX to validate the provided credentials and set a session. So, when someones logs in our website, they have automatically access to the API as well.
Developers can authenticate theirself through the API using HTTP-Basic over SSL, which will as well generate a session and give them access to the services they are authorized to call.
Also, Developers and clients can gain access to the website and the API using their facebook account through the Facebook Connect functionality. This deletes the step where each actor has to create an account on our website.
So basically, the credentials are provided either through HTTP-Basic or using the Facebook Login functionality.
Now that my authentication system is working and that my clients are able to access the website, I would like them to connect to a real-time server when they log in. Like in Facebook or Google+ if you want where the real-time server manages chat and push informations.
In this case i'm using Node.js and the powerfull socket.io library to manage everything that deals with the real-time side.
Of course, the real-time service will need some credentials to authenticate the user since he is authenticated to the Symfony security system with a session but is not authenticated against the real-time server.
A solution I've been thinking about would be to use the PdoSessionStorage in my API (Symfony side) and store all the active sessions in a database such as MySQL or PostgreSQL. Doing so, I would be able to send to my real-time server the session id generated by symfony and check on the database if the session id provided is correct or not. If he is I'll let the user access the services provided by my real-time server and associate his session with an identity.
But I really don;t know if this is a good solution and I would like some more experienced advices on this and on how to deal with this issue.
Note : For some reasons, I cannot implement OAuth even if it could be a solution to solve this issue using a Single Sign On approach.