Closed rfdickerson closed 8 years ago
Beautiful! This is a great idea! I think the AuthenticationStrategy
protocol is a nice way for us to support both hard-coded username/password credentials (used to obtain a token, of course) and any custom authentication methods that clients may want to implement.
I think the big win here is that it makes it easy for clients to configure their own proxy. This is a great solution to the IPA security problem.
I do have a few questions:
Automatically refreshing tokens. As it stands, I assume a service with an expired token would: a) try to use the token, b) receive an "invalid token" response, c) call authenticate
to refresh the token, then d) try the call again with the refreshed token. Do you think that would work, or are there any "gotchas" you see that might prevent it from working?
As an alternative, what are your thoughts on an expiration: NSDate
property to help proactively refresh tokens instead of reactively refreshing them?
onauthenticate callback. I'm a bit confused about how this would be used in practice. When would it be called?
I assume the SpeechToText service would request a token during initialization. But unless the token request is a blocking call, the init function may return before a valid token is retrieved. Is there a way to prevent clients from calling SpeechToText functions before a valid token is retrieved? Here's the kind of situation I'm thinking about
SpeechToText is initialized, prompting a token to be requested Client requests a transcription, which fails because the token is invalid Token is received
AuthenticationStrategy
protocol?Great! We should discuss some of the details today.
Subsequent calls with an unbeknownst invalid token could do:
Ah, now I see. Thanks for the post! That helps a lot.
I wonder if there's a convenient way to abstract some of that. Maybe services construct a request object and pass it (along with the AuthenticationStrategy
object) to a "gateway" that handles retrieving/refreshing tokens?
I know we played around with a gateway early on, but it didn't seem necessary at the time.
Either way, we should probably spend some time to hammer out the design decisions to incorporate the AuthenticationStrategy
. I'm still a bit confused about the best way to handle network calls and responses while incorporating tokens.
Great work on this!
Proposal
The SDK needs to support multiple authentication types for:
The proposal is to use the Strategy design pattern to encapsulate the concerns of authentication to a class instead of the service that uses the authentication. All implementations of AuthenticationStrategy must implement the authenticate method. We would implement for our users the first 3 types, allowing them to create additional strategies if they need it.
Advantages
Example: Basic Authentication
In this example, the BasicAuthenticationStrategy is constructed with a username and password field as well as the URL for obtaining the token.
Instantiating the SpeechToText service would require an authentication strategy:
To use Facebook OAuth, one would change the call to:
Notes