As like oAuth we can synchronise users authentication information with third party applications or websites, I want to integrate iCloud calendar service with my rails application. From where on button click user is asked to provide their iCloud credentials and after verifying user my rails app should allow that user to access his iCalendar events(Dynamic event generation).
I already tried to add iCloud calendar account with chronofy but it's not recognising my APP-SPECIFIC-PASSWORD.
So is this possible, preferably with some kind of oAuth setup as we do it with Google Calendar? or are their any API which can carry out my task, if so where can I find documentation on the API?
Apple do not provide a public OAuth mechanism for iCloud so its not possible to access their API directly
Related
I am providing sign in with google functionality on my application. Users are able to successfully login using that but my application is not showing in "Manage third party apps" section of user's google account when they login. So they do not have an option to revoke access for my app. Any ideas on what I am doing wrong here I want my app to be listed in users "Manage third party apps" section when they login successfully.
I think you are miss understanding what third party apps is. You may want to consult Manage third-party apps & services with access to your account
For example, you may download an app that helps you schedule workouts with friends. This app may request access to your Google Calendar and Contacts to suggest times and friends for you to meet up with.
Third party apps use Oauth2 to request your consent for the application to access your data. When you consent to this the application in question is given a token (refresh token) which will allow them to access your data until you revoke that access. They can access this data without you being there. So they could have something running every night to harvest your data. They have access even when you are offline. The way you revoke it is though the security page on your google account.
Sign-in does not grant any access in that manner. For signin to work you the user must be behind the machine when it is running. The application you signed into cant access your data when your offline.
There is no way for you to know which applications you have signed in using your google account. Unless they also requested some Oauth2 consent.
So again sign in is Open IdConnect and does not make it by itself a third party app. They have no access to your data after you are gone. Signin only works when the user is behind the machine.
Our company uses Sign in with Google to log into various third party applications (e.g. Atlassian Jira/Confluence, Coda, Dropbox, Hubspot etc.).
I have been able to use the Admin SDK to get API access to each user's email, calendar, drive via the domain-wide delegation. Is it possible to delegate access to all the third-party apps that are connected to the user's Google accounts too?
Ideally, I want to be able to use the third-party APIs (just the way I'm able to use Gmail, Drive, Calendar APIs) on behalf of the users—without having the users grant my application explicit access (via OAuth) for each third-party app.
It really depends on the third party app. As you noticed your users can give you (scoped) access to some other app (GSuite apps for your example) but there are more apps out there!
What prevents your user to give you access to other third party apps is the third party apps implementing this.
Let's say your users log in to spotify using a Google account for which you have scoped access to say, gmail. Your app picks up that there is a new service in town by reading the registration email from spotify and prompts the user to give access to say manage playlists and play music apt to the email begin written.
If spotify does not implement an API where the user can grant access to an app this can't be done. Also the user must grant access to some resources, say playlists, and everything else will not be available to you.
Each user must grant access, usually in form of a token that is negotiated between the service you want to call on behalf of the user, say spotify, and your app.
In our example it's spotify that grant access once you present your token and the only way to get a token would be to ask the user a grant which is usually done through some OAuth dance.
GSuite has many apps and you can set up different policies but spotify is a different app/company and is not covered by your domain-wide delegation so you really need to ask the user and the user has to grant you access.
If by any chance the third party app has some strange deal with GSuite that's another story but this is the general case.
I'm trying to build a Google Apps Marketplace App using the new APIs only available through OAuth2. We already have an app using the old APIs, but I'm having trouble figuring out how to have the same flow with OAuth2.
In our old app, the domain administrator would install the app and give it permissions. Then, we could just make requests using our app's id/secret without user interaction. (2-legged OAuth)
How would I do this with OAuth2? None of the flows described here sound like what I'm looking for.
I'm also having hard times to find out to get this new OAuth2 login up and running.
You will have to use service accounts to make requests on behalf of the user.
Documentation is here:
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
I did not yet manage to get the flow working without each user being prompted again, but this most likely is because I need offline access:
Google Apps Marketplace SDK + Domain-wide OAuth 2 SSO
I'd like to be able to access a user's iCal and create events from my server, is this possible, preferably with some kind of OAuth2 setup like with Google Calendar? If so where can I find documentation on the API?
Unfortunately no. There is currently no OAuth whatsoever for iCloud. However, there are two solutions to consider:
Ask the user for their AppleID and password and store it on your server (not recommended for security reasons). This will allow access to EVERYTHING the user has enabled on their account; even the ability to log in and purchase content - thus the security issue. But it will give you direct access to iCal.
Ask the user for access to calendar through your app. Using EKEventStore requestAccessToEntityType: method you can gain access to the users local calendar. You could batch those events and send them to your server. You can find information on how to access calendar here.
It is possible. iCloud supports CalDAV on caldav.icloud.com, and that quite well. It allows you to create, modify and delete events and tasks. Unfortunately you have to have the user's credentials for this though.
In general, what's the best practice to authenticate a user via 3rd party (say Twitter) using iOS's ACAccountStore and then tie it to an existing user in my own service assuming that they were logged in already? Can I access and store the account credentials remotely over ssl, or is there a better way?
And if they had to re-login via Twitter, I could just search for the user with that twitter handle to know what backend user is tied to this account, yes?
And lastly if I wanted to be able to login via a browser later on, I would get new oauth credentials for the webapp as well, but could search for a user with the same Twitter account info and store these credentials as well, and know that they all refer to the same person, correct?
What you're asking involves many levels of a system "stack" that are custom to a particular environment. What is "correct" vs "incorrect" is dependent upon the environment you've set up and are connecting to from your iOS app.
So from what it sounds like you're leveraging iOS's Twitter functionality to create a Single Sign On (SSO) experience. There are several guides on Twitter's site for doing what you want to accomplish:
Integrating with Twitter on iOS: Single Sign On
Using Reverse Auth to Get OAuth Tokens on iOS - you can then store these server-side
Migrating tokens to system accounts - how you get OAuth tokens from your webapp to iOS.