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

tvOS support #111

Closed
DarkDust opened this issue Apr 20, 2017 · 12 comments
Closed

tvOS support #111

DarkDust opened this issue Apr 20, 2017 · 12 comments
Assignees
Milestone

Comments

@DarkDust
Copy link

Right now, there doesn't seem to be official tvOS support (at least the documentation isn't mentioning anything) even though the pod does compile on tvOS.

Since tvOS does not have a browser, how is an app supposed to use AppAuth here? Is it possible with the current AppAuth release or would changes be necessary?

As a side-note, we operate our own OpenID service.

@iainmcgin
Copy link
Member

If you are just signing in to your own OpenID service, you could build a native login flow for that and don't really need AppAuth. However, if you are instead asking how others could integrate with your service as a relying party, it's not really possible on tvOS - without a system browser, you would have to trust these relying parties to directly handle your user's credentials.

The safer solution would probably be some "second screen" flow, where you have the user authorize the tvOS app using another device (like their iPhone / iPad). This is of course outside the scope of what OpenID Connect defines.

@panva
Copy link
Member

panva commented Apr 20, 2017

@DarkDust this might be useful to you - https://tools.ietf.org/html/draft-ietf-oauth-device-flow

@DarkDust
Copy link
Author

Alright, thank you for clarifying this. We already suspected that we cannot solve this with AppAuth due to the design goals of AppAuth. The "second screen" flow as specified in the draft is what we already had in mind and is our long-term goal: nobody wants to enter long complicated user names and passwords on tvOS anyways ;-). Since we control both app and authentication service we went with a password flow for now.

@WilliamDenniss
Copy link
Member

The Google extension to AppAuth includes tvOS support. However, it is hard-coded to Google, and the protocol is an out-of-date draft version of the OAuth Device Flow specification.

I have a fork here: https://github.com/WilliamDenniss/GTMAppAuth/tree/interop to prove interoperability with the latest draft specification (the differences are fairly minor).

My plan is to move this feature into AppAuth proper once the draft is submitted for publication. Until then, I would recommend starting with my interop branch, and the current draft RFC.

Incidentally, this is the same auth protocol YouTube TV uses for Sign-in across all surface areas.

@WilliamDenniss
Copy link
Member

Status of tvOS code in GTMAppAuth

An update on the status of the tvOS support in GTMAppAuth (Google's open source AppAuth extension):

The tvOS code was removed from the GTMAppAuth releases. The branch tvos-authorization was created just before removal, which points to commit google/GTMAppAuth@10d138e

I have my own fork of that branch here. In my fork, I've deleted the rest of the GTMAppAuth code. This fork is not ready for use, but could serve as a starting point for moving this code into AppAuth.

@WilliamDenniss
Copy link
Member

WilliamDenniss commented Jun 2, 2020

Integration Proposal

Here's what I recommend we do. Now that the RFC 8628 is published, which specifies the device authorization grant and covers the tvOS use-case, it's a good time to integrate this code into AppAuth itself.

In order to support tvOS in AppAuth, I suggest the following:

1. Move the code into AppAuth

Start by moving the tvOS code formerly part of GTMAppAuth into AppAuth. Specifically, the classes:

GTMTVServiceConfiguration The configuration of the service
GTMTVAuthorizationService Code responsible for performing the tvOS flow itself
GTMTVAuthorizationRequest Representation of the RFC 8628 request
GTMTVAuthorizationResponse Representation of the RFC 8628 response

As well as the example code in Example-tvOS.

2. Create a sub-spec

This code should not be built for every user of AppAuth, but rather only those who want this support.

Since this code is more than platform-specific user-agents, which in the AppAuth pod we just bundle with the relevant platforms, what I recommend in this case is to create a dedicated sub-spec, AppAuth/tvOS, or AppAuth/RFC8628 to contain this code.

3. Refactor for AppAuth

  • For this library, the GTM prefix should be changed to OID.

4. Update with spec-compliant RFC 8628 support

The original implementation was made before RFC 8628 existed. It's mostly similar, but there are some fixes that need to be made:

  • GTMTVDeviceTokenGrantType const should now be urn:ietf:params:oauth:grant-type:device_code
  • verification_url is now verification_uri code, and the property verificationURL should be renamed to verificationURI to match
  • The device code is passed as "device_code" in the token request
  • Default interval value of 5.

You can reference the following patch WilliamDenniss/GTMAppAuth@463efbd for a very rough implementation of these changes. This patch can be a starting point, but will need to be cleaned up.

Note that Google's implementation currently returns verification_url, not verification_uri (a bug has been filed to add verification_uri). Generally AppAuth does not cater for implementation-specific workarounds. In this case, since you'll likely be testing against Google's implementation (as one of the few public implementations out there) the code could temporarily accept both keys.

5. Update the Sample

The sample should follow the approach that AppAuth takes by not hard-coding a specific IdP (currently they use Google), and instead having generic values, with a README describing how they should be set.

@WilliamDenniss WilliamDenniss self-assigned this Jun 2, 2020
@soule
Copy link
Collaborator

soule commented Jun 2, 2020

Sounds good!

@WilliamDenniss
Copy link
Member

I started a dev branch for collaboration on this. https://github.com/openid/AppAuth-iOS/tree/dev-tvos

Work completed:

  1. Imported the tvOS code from GTMAppAuth
  2. Updated implementation from returning GTMAppAuthFetcherAuthorization objects to OIDAuthState
  3. Initialized the subspec (AppAuth/TV)

It builds, but I've not tested it.

Over to you @soule!

@petea
Copy link
Collaborator

petea commented Aug 20, 2020

I think we've wrapped this up. Should we mark this closed?

@petea petea added this to the 2.0.0 milestone Aug 20, 2020
@yalkhder
Copy link
Collaborator

SGTM!

@petea petea closed this as completed Sep 22, 2020
@petea petea modified the milestones: 2.0.0, 1.5.0 Mar 16, 2022
@wekrato
Copy link

wekrato commented Dec 14, 2022

I tried to use pod 'AppAuth/TV'
but when I do pa pod install --repo-update I get this error:

[!] CocoaPods could not find compatible versions for pod "AppAuth/TV":
In Podfile:
AppAuth/TV

None of your spec sources contain a spec satisfying the dependency: AppAuth/TV.

You have either:

  • mistyped the name or version.
  • not added the source repo that hosts the Podspec to your Podfile.

Am I missing something?

@wekrato
Copy link

wekrato commented Dec 15, 2022

I found the error. The subspec for tvOS is only available starting from version 1.5 and I used AppAuth with 1.4 in the same project. This was the reason why it was not found.
Just in case somebody else runs into similar problems.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

8 participants