Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does Fastlane support Apple's mandatory two factor authentication? #14239

Open
joelgetaction opened this Issue Feb 13, 2019 · 44 comments

Comments

Projects
None yet
@joelgetaction
Copy link

joelgetaction commented Feb 13, 2019

Question Checklist

Question Subject

Fastlane and its management of certs and signing.

No

No

Question Description

Apple is making two factor authentication MANDATORY for all use of the developer portal and starting February 27, 2019. See https://support.apple.com/en-us/HT204915

Will this break Fastlane? Will Fastlane still be able to manage certs etc? If not, how can we update Fastlane so that it can still work with 2FA?

@abotkin-cpi

This comment has been minimized.

Copy link

abotkin-cpi commented Feb 14, 2019

@janpio This ties to what I was saying in #14200 that there will be a segment of fastlane users looking for a 2FA upgrade guide given the recommendation in the CI Best Practices that setting up without 2FA with a CI-specific Apple ID is the easier way to go (and first on the page).

@joelgetaction

This comment has been minimized.

Copy link
Author

joelgetaction commented Feb 14, 2019

@abotkin-cpi and @janpio I think we should probably work on the assumption that Apple will require 2FA on all developer accounts because that feels safest and the most likely to succeed for all Fastlane users. So ideally we need to make Fastlane work with 2FA.

The reason I doubt that a CI-specific Apple ID is doable and practical for most Fastlane users is:

  • On https://support.apple.com/en-us/HT204915 it says:
  • On https://support.apple.com/en-us/HT204152 they say:
    • "If you use two-step verification for your Apple ID, and then you upgrade to iOS 11 or later, or macOS High Sierra or later, your security settings may be automatically upgraded to two-factor authentication." - Does this mean that if you access your CI-specific account that you setup two-step authentication for on an iOS 11 device or macOS High Sierra or later, even once, that you ability to use that CI-specific account without 2FA will be blocked now?
    • You can generate app-specific passwords for two-step verification and these might work with Fastlane
    • Can the trusted device used to verify two-step authentication codes also be signed in to an apple ID that itself uses 2FA? Many devs can't feasibly afford to keep an Apple device just for two-step authentication

I may be making more out of this than there really is, but it sounds concerning to me. I've filed support and forums issues with Apple asking these same questions and I'll report back here with what I find.

Thanks for your hard work on Fastlane, it is a very cool and useful tool and I really appreciate it! :-)

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 14, 2019

Yes, Fastlane already fully supports Apple's 2FA (and the older 2SV).

If you use Fastlane in an interactive shell, where you can input stuff, it will just ask you for the 2FA code or 2SV token (sent via push or even SMS to your device) exactly as the website does.

On CI (or other systems where you can't just input some code) there is an alternative solutions available as well: https://docs.fastlane.tools/best-practices/continuous-integration/#two-step-or-two-factor-auth

We are in the process of updating that documentation to be clearer and reflect the new reality of required 2FA.

@janpio janpio changed the title Will Fastlane support Apple's mandatory two factor authentication? Does Fastlane support Apple's mandatory two factor authentication? Feb 14, 2019

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 14, 2019

@joelgetaction See my first response.

A lot of your confusion is probably because 2FA (2 factor authentication) and 2SV (2 step verification) are two different things at Apple. 2SV is the old system, where you get a 4 digit code to verify that worked on devices older than iOS 11. 2FA is the newer system, you get a 6 digit code, and only works for devices from iOS 11. So the link in your second bullet point is mostly about their upgrade path from 2SV to 2FA.

Fastlane supports both 2SV and 2FA, so we are good there.

@18padx08

This comment has been minimized.

Copy link

18padx08 commented Feb 14, 2019

So starting in December we had this issue Two factor sessions only lasting a few hours , so we started to go back to non 2fa setups, since it was not feasible for us to manually update the sessions every few hours. Do you have any solution yet? I could not find any updates on it, and the issue was auto-closed...

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 14, 2019

From my observation, this was a temporary thing. But I haven't worked too much with two factor sessions in the last few weeks. (Although that not many new issues were opened also points to the problem being solved or at least not as drastic any more.) We need your observations here to be able to make any statements @18padx08

@ScottRobbins

This comment has been minimized.

Copy link

ScottRobbins commented Feb 14, 2019

I'm curious if the hassle of 2FA requirements may change fastlane's position on using the app store connect api / api keys

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 14, 2019

What do you refer to @ScottRobbins? What alternative do you have in mind?
(Although best move this discussion to a new issue - that would be best.)

@jeremyspatrick

This comment has been minimized.

Copy link

jeremyspatrick commented Feb 14, 2019

Is there any way to use an application specific password (FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD) for cert, sigh etc. and not just deliver?

When dealing with a production build server that is not easily accessed and for many many apps/logins we can't have someone logging into the server with a basket full of ios devices entering mfa codes once a month.

@ScottRobbins

This comment has been minimized.

Copy link

ScottRobbins commented Feb 14, 2019

@janpio It's mainly the same as this issue: #12713

ITMS Transporter and App Store Connect API allows the use of API keys for authentication as opposed to using username/password of a dummy CI user.

Theoretically you then wouldn't need to generate a session token once a month. But this conversation can be continued on that thread.

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 14, 2019

Oh, we would love to be able to switch over!

But for now most functionality is just not available via the API. @joshdholtz is working on implementing the Testflight part I think, but besides that the important things are still missing: Creating, managing and downloading certificates and profiles, app IDs and app metadata etc.

PS: Do you have a source on the iTMS Transporter usage of API keys? If so, please open a new issue for this and we can start working on it. Although iTMSTransporter uses and still works with app specific passwords, getting rid of that part of the codebase might be a good idea.

@stevekohls

This comment has been minimized.

Copy link

stevekohls commented Feb 14, 2019

@janpio @ScottRobbins I did a little sleuthing:
Make your way to /Applications/Xcode.app/Contents/Applications/Application Loader.app/Contents/itms/bin
And do a:

$ ./iTMSTransporter -help upload

And you'll see:

...
 -apiIssuer <arg>                      The -apiIssuer option specifies your App Store
                                       Connect Issuer ID.  You must also include the
                                       -apiKey option.
 -apiKey <arg>                         The -apiKey option specifies your App Store
                                       Connect API Key ID.  You must also include the
                                       -apiIssuer option. This option will search the
                                       following directories in sequence for a private
                                       key file with the name of AuthKey_<apiKey>.p8:
                                       ./private_keys, or <user home>/private_keys, or
                                       <user home>/.private_keys, or <user
                                       home>/.appstoreconnect/private_keys.
...
 -jwt <arg>                            The -jwt option specifies a JSON web token.
                                       You cannot use the -jwt option with the
                                       apiIssuer and apiKey options.
@ScottRobbins

This comment has been minimized.

Copy link

ScottRobbins commented Feb 14, 2019

made an issue here

@joshdholtz

This comment has been minimized.

Copy link
Contributor

joshdholtz commented Feb 14, 2019

The response @janpio gave is correct. We would love to switch over to using the new auth system with the API keys but the API keys are not backwards compatible with the private APIs that most of fastlane is built upon.

So what we currently have to do is use the username/password sessions as those work with the private APIs and because the username/password sessions also work with most of the new App Store Connect API (as this is what the App Store Connect website uses).

If we were to add the use of the App Store Connect APIs, fastlane would currently lose about 90%+ functionality 😔 We are working on slowly adding new APIs that we need in order to keep things working. We may add support for the API keys here soon but it would only provided a limit set of things that fastlane and all of its tools can actually do.

This may have been a longer answer than needed but this is the current state of the new App Store Connect APIs in fastlane 😇

@gholias

This comment has been minimized.

Copy link

gholias commented Feb 15, 2019

Is it possible to have an Env Var with the 2FA code? Something like FASTLANE_2FA_CODE and when Fastlane tries to login and the 2FA is requested it uses that env var instead of asking the user to input it?
I have a crazy idea to make my CI server to be waiting for the code from the 2FA SMS and when it gets it, start a session using fastlane spaceauth -u user@email.com and then kick the CI build.

@Wouter33

This comment has been minimized.

Copy link

Wouter33 commented Feb 15, 2019

@gholias Apple probably links a 2FA code to a login session. If that is the case you can't have a 2FA code before fastlane triggers the login with username and password.

What maybe could work in a (semi)automated way is that fastlane breaks up the singin in into two steps:

  1. Login with username and password. 2FA required, send status/webhook/event and end process.
  2. Second command resumes the login session with a 2FA code provided via CLI/ENV.
@18padx08

This comment has been minimized.

Copy link

18padx08 commented Feb 15, 2019

@janpio As soon as I have some time I will check what the current state is for the session thing for our projects and will respond here 👍

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 15, 2019

@gholias We have thought about similar ideas (and talked about it in some issue) before, so yes this would probably be doable - although with the constraints @Wouter33 mentioned as far as I know.

But we can definitely work on something to improve the spaceauth process. Could you please create a new feature request issue and pull me in so we can discuss the further details? Thanks!

@gholias

This comment has been minimized.

Copy link

gholias commented Feb 15, 2019

@janpio I created the feature request issue #14249

@garylai

This comment has been minimized.

Copy link

garylai commented Feb 17, 2019

So starting in December we had this issue Two factor sessions only lasting a few hours , so we started to go back to non 2fa setups, since it was not feasible for us to manually update the sessions every few hours. Do you have any solution yet? I could not find any updates on it, and the issue was auto-closed...

@18padx08
I generated a session last Friday and it worked for the whole day (office hours I mean). But it has expired when I come back this morning. There is a max_age: 1800 in the session so I assume that the session is now only valid for 30 hours...

The session prints by fastlane spaceauth -u <apple_id> is different from the one in ~/.fastlane/spaceship/<apple_id>/cookie. There are only 2 domains: apple.com and olympus.itunes.apple.com in the former while there more like idmsa.apple.com in the latter. The max_age for idmsa.apple.com is longer as well.

@garylai

This comment has been minimized.

Copy link

garylai commented Feb 18, 2019

It looks like only account holder's account is affected by this Apple change: https://www.bleepingcomputer.com/news/apple/apple-requiring-2-factor-authentication-on-developer-account-holders/

Only the account holder Apple IDs of a team received emails about mandatory 2FA. admin Apple IDs and Individual account account holder haven't had it. So it looks like it is really the case. We are trying to contact Apple to confirm as well.

@18padx08

This comment has been minimized.

Copy link

18padx08 commented Feb 18, 2019

@janpio @garylai
Same for me, I created a session last Friday, which wasn't valid anymore today.

@garylai Could you post an update as soon as you get any response by Apple? :)

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 18, 2019

The session prints by fastlane spaceauth -u <apple_id> is different from the one in ~/.fastlane/spaceship/<apple_id>/cookie. There are only 2 domains: apple.com and olympus.itunes.apple.com in the former while there more like idmsa.apple.com in the latter. The max_age for idmsa.apple.com is longer as well.

Very complicated topic, seems we have to look into this again. Might help if you contact me with the cookies you are seeing, then I am not only looking at my own data.

@garylai

This comment has been minimized.

Copy link

garylai commented Feb 18, 2019

@18padx08 confirmed with Apple that only Account Holders are affected:

After reviewing your Apple ID, it appears as though you are not currently listed as an account holder for an Apple Developer team. This new requirement will not currently affect you or your account access. If in the future you decide you would like to be an account holder of an Apple Developer Program membership, you will then need to enable two-factor authentication.

@garylai

This comment has been minimized.

Copy link

garylai commented Feb 18, 2019

@janpio My team is not going to pursue further at this point so I will not be looking into the cookie anymore. Thanks you for your help. If you need more data to investigate the cookie please let me know. I am happy to help.

@gholias

This comment has been minimized.

Copy link

gholias commented Feb 18, 2019

If Apple is only forcing on the account holder it means I dont need to change my current CI workflow. I will keep using the secondary account for the CI builds

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 19, 2019

Thanks for that confirmation from Apple @garylai - that "suboptimal" first communication from Apple caused a few busy days for us all. Phew.

Will create a roundup issue for this later so more people learn about it.

@18padx08

This comment has been minimized.

Copy link

18padx08 commented Feb 19, 2019

@garylai Thank you very much!

@rlindner

This comment has been minimized.

Copy link

rlindner commented Feb 20, 2019

This has just been officially confirmed again here: ‪https://developer.apple.com/news/?id=02202019a‬

@ZonD80

This comment has been minimized.

Copy link

ZonD80 commented Feb 21, 2019

What if just ping apple after entering 2FA code every N hours to keep session alive? is it an option?

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 21, 2019

Even further via mail from Apple:

You are receiving this email because you have the Account Holder role in a developer program, with full access to tools, resources, and benefits included with your membership. In an effort to keep accounts more secure, two-factor authentication will be required to sign in to your Apple Developer account and Certificates, Identifiers & Profiles starting February 27, 2019. This extra layer of security for your Apple ID helps ensure that you're the only person who can access your account.

(The account that received this has 2FA activated already...)


@ZonD80 That depends on if they actually extend the session length, and if spaceship correctly handles updating the session cookie. Some testing there would be greatly appreciated!

@ZonD80

This comment has been minimized.

Copy link

ZonD80 commented Feb 21, 2019

@janpio okay, i'm on it. We will test it on Friday.

@ZonD80

This comment has been minimized.

Copy link

ZonD80 commented Feb 22, 2019

@janpio here are some tests:
Spaceship::Portal.login(email, password) - acquires 2FA session cookie and with second login it remains the same - so no cookie is updated after login. However, via browser, apple sends the same cookies, but with another expiration date (+year). I guess we need to change behavior to updating of local session cookies with every login/request.

Upon cookie deletion (removal of file) - it requires new 2FA PIN code, so i guess their "Trust" button is only cookie life extension, because it is not working if i using incognito mode.

I've placed a worker in our system to auth on dev portal every 600 seconds, let's take a look, will it survive till Monday or not.

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 22, 2019

Hey everyone that posted here, I am currently working on a first improvement to the 2FA handling of fastlane/spaceship: A way to define which phone number should automatically be selected for the 2FA token.

I need some help with the output on the Apple UI though: #13980 (comment) Would be great if some of your with "trusted phone numbers" in their accounts could take a look and reply. Thanks!

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 22, 2019

@ZonD80 I created #14301 to continue this discussion and observations, so we don't spam all the other people that were involved in this issue. Everyone interested in our findings should subscribe to this issue. Thanks.

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Feb 23, 2019

@zargox posted in the wrong topic, so I copy it over here:

Regarding "Account Holder role", it is needed to have this for "individual" companies for creating session cookies in Fastlane. For other organizations it is not needed to work with fastlane session cookies, you can add your email address as a member, and access the account.

So yes, for "individual" accounts there is no way around 2FA for certificates etc.
For App Store Connect, you can also use additional accounts though.

@ericnondahl

This comment has been minimized.

Copy link

ericnondahl commented Feb 27, 2019

I had trouble getting fastlane to work for our simple use case of just uploading an IPA on CI. New Apple ID accounts seem to require two factor in the setup process now, so a "dummy" account without two factor becomes less of an option if you don't already have one.

For this very simple use case, the altool from apple is good enough.
https://help.apple.com/itc/apploader/#/apdATD1E53-D1E1A1303-D1E53A1126

Using the altool, you can send in an Apple ID username (that has two factor enabled) with an app-specific password and there is no prompt for two factor. Looks something like this on jenkins:

sh "\"/Applications/Xcode.app/Contents/Applications/Application Loader.app/Contents/Frameworks/ITunesSoftwareService.framework/Support/altool\" --upload-app -f ${ipaPath} -u username@email.com -p ${UPLOAD_PASS}"

@fishercraigj

This comment has been minimized.

Copy link

fishercraigj commented Feb 28, 2019

Hey friends - Figured out a work around. Create a new user in AppStoreConnect. Make sure to only add them as an App Manager that has access to the certs and provisioning profiles. There's a little check box for that. Make sure your new user credentials are stored however your usually store yours for your fastlane runs. Kick off a build and you should be back to normal.

What I've found, despite what Apple actually says about who's required to use 2FA, there are still underlying AppStoreConnect bugs. IE: Whey the say only the Account Holder will be required to use 2FA. While that is true, if your user is an Admin, you still ironically don't have access when running things like sigh. Watch your build logs and you'll see what I mean. I think there is a bug differentiating Account Holders/Admins on Apple side. So even though the admin doesn't require 2FA, you don't have all the access that you need.

But if you take a lower access of "App Manager" with access to certificates and provisioning profiles then you're good to go. I'm pretty sure the AppStoreConnect QA team was on vacation during the time they were supposed to be testing this.

Hope this helps someone!

@ZonD80

This comment has been minimized.

Copy link

ZonD80 commented Feb 28, 2019

Thank you! That's so odd, what's the point of having 2FA then?

@fishercraigj

This comment has been minimized.

Copy link

fishercraigj commented Feb 28, 2019

I think the intent is only to basically block something bad happening with whomever has the "account holder" credentials.

@RacingWang

This comment has been minimized.

Copy link

RacingWang commented Mar 13, 2019

Hi all, I only run the upload action in my fastfile, and I setup the FASTLANE_APPLE_APPLICATION_SPECIFIC_PASSWORD env already (https://docs.fastlane.tools/best-practices/continuous-integration/#use-of-application-specific-passwords-and-spaceauth). However, it still requires me entering the password and 2FA code of my Apple ID before uploading. Why?

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Mar 14, 2019

What upload action are you talking about exactly @RacingWang? Best create a new issue and mention me there, so we don't notify all the people that participated in this issue here. (Probable answer: Anything that touches metadata does not work with an app specific password)

@madfingo

This comment has been minimized.

Copy link

madfingo commented Mar 16, 2019

As with @ericnondahl, I needed to use altool to bypass the annoying prompt and login only with the user and app_specific password.

fastlane upload_to_testflight and fastlane pilot upload should be able to do the same.

@janpio

This comment has been minimized.

Copy link
Collaborator

janpio commented Mar 18, 2019

They are able to do that @madfingo, if you don't do anything that uses a different API. I created #14342 to create its own action that by default is "application specific password" safe.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.