#Apple java script code#

So, the end result of all this is that the callback URL will get a POST from Apple with some information about the user, which looks like:

#Apple java script code#

Keep in mind that if you click “Trust,” you’ll have to clear your cookies and cached browser data to get it to prompt you for a 2FA code again before the thirty days are up. Luckily, there’s a “Don’t Trust” button which, if selected, will never ask you again if you want to trust this browser, and simply requires you to use a 2FA code every time. For me, this is a big no-no since 2FA is one of the key things that makes Sign in with Apple more secure.

If you trust the browser, then for the next 30 days you won’t be required to use the 2FA code to get in. One of the first steps in completing the Sign in with Apple process is to decide if you want to trust the browser you’re using.

The great thing about this as a user is that you can disable the forwarding if you end up getting a lot of unwanted spam. If the website asks for email address, the user may share the actual email address in iCloud, or a “relay” version of it. This allows the name sent to the website to be just about anything. Users who want to share their name can change it without affecting their iCloud info-which is nice. The login process then asks the user if they want to share the information (name and/or email) the website is requesting. This code is then entered into the website. Below, we see it showing up on Apple Watch. If this is the user’s first time using this process at a specific site, a 2FA code will be sent to the user’s Apple-trusted device(s) with an authorization code. When the user clicks the link, they’ll get a login prompt to enter iCloud credentials. Service information that defines what App ID/Service ID is being used to handle the authorization.Scope being requested, name, email or both.Redirect URL to handle the callback from Apple.Create a link from the button to the authorization URL, passing the following info:.The Service ID information is then used as the client ID for getting the access token in the OAuth flow. Setup an App ID and Service ID in your Apple Developer Account.But there are a few things you’ll need to setup before we get to the actual REST call: Implementing Sign in with Apple is fairly straightforward via REST, which follows an OAuth protocol. Getting your first successful integration can take a bit and going the REST path reduces the complexities and lets you use the server-side language of your choosing. The user still signs in via a browser session, but instead of using Apple’s JS framework the authentication points are server-side.įor this blog post, we’ll focus on option 3, because it’s the easiest way to get started (and functionally, the same as 1 and 2). REST based – use Sign in with Apple REST API to allow REST-based authentication flow.Browser Integration – Use Sign in with Apple JS which is a JavaScript framework to handle using Sign in with Apple directly in a web browser.Native App Integration – use AuthenticationServices framework for native iOS, macOS, tvOS, and watchOS apps.

You enter your credentials and verify it’s ok for the app (or site) to use your information (and what information they should have access to).įrom a developer’s perspective, there are 3 ways to implement Sign in with Apple: This will let anyone with an Apple ID and a trusted device use this feature on any app or website that supports it.įrom a user perspective, Sign in with Apple is virtually identical to any 3rd party OAuth-based SSO. One of the more interesting new features in iOS 13 is “Sign in with Apple,” which allows you use your Apple ID to sign into 3rd party apps, and even websites.