Getting access to HTTP header fields from the UserProfileDelegate update method

[crspybits]

I'm using your CredentialsGoogleToken to sign in a user on a server, where the user signed in originally on an iOS mobile app using Google Sign in. Because my server operates somewhat independently of the mobile app, it's important for me to pass along a Google Sign in server auth code (https://developers.google.com/identity/sign-in/web/server-side-flow). This is used on the server to obtain a server-side refresh token, in addition to obtaining an access token. I think it makes sense for me to pass that server auth code up to the server as a HTTP header-- since its authentication related.

Thus, it would seem to make sense to add a parameter to your UserProfileDelegate update method that provides access to the HTTP headers. E.g.,

func update(userProfile: UserProfile, from dictionary: [String:Any] andHeaders:Headers)

[irar2]

I am sorry, I don't understand what you are trying to do here.
The update method updates the user profile with the data received from the authentication provider. Do you mean that Google sends an additional token to CredentialsGoogle in an HTTP header, and you want to pass this token to the application using UserProfile?

[crspybits]

Thanks for your response. What you are saying is close to what I'm doing with a couple of differences:

1. I'm using CredentialsGoogleToken not CredentialsGoogle.
2. It's my iOS app that's sending the HTTP header. I have an iOS mobile app, which connects to my server. This app uses mobile-app side Google Sign In to generate an access token and a server auth code. What I want to do is to ship the server auth code up to my server in an HTTP header. However, if I use CredentialsGoogleToken the way it is currently, I don't have access to the HTTP headers (e.g., using the UserProfileDelegate) to obtain that server auth code.

The server auth code is exchanged for a refresh token on my server. That refresh token has to be stored in my server's database, so it can later be used to generate new access tokens. Hence my need for getting it to my server application.

[irar2]

So, you want to pass the headers of the original request (the request that contains the access token) to UserProfileDelegate, right?

[crspybits]

Yes, that's what I want to do.

[irar2]

@crspybits I talked to our Swift@IBM security expert and in her opinion it is not a good idea. We don't understand why the server needs to communicate with Google, it seems that the right way to do that is from the client.
If you still want to pass an auth code to the server, you can write a middleware to extract the desired info from the request, and put that middleware right after the Credentials middleware.

[crspybits]

On the We don't understand why the server needs to communicate with Google-- Communicating from the server to Google is the procedure recommended by Google for servers that need offline access to the client's data. See for example:
https://developers.google.com/identity/protocols/OAuth2WebServer#offline
https://developers.google.com/identity/sign-in/web/server-side-flow
http://stackoverflow.com/questions/30637984/what-does-offline-access-in-oauth-mean

In my case, I'm developing a server that enables Google users to authenticate users with other credentials (e.g., Facebook) to access their Google Drive info. So, that's a natural case where offline access is needed.

[gtaban]

Hi @crspybits, I was the one that recommended that adding a header field to that delegate API might not be a good idea.
I completely understand your reason for wanting offline support from the token and this particular flow seems perfectly suitable for it. I should admit from what you had written before it seemed you wanted to refresh your client side token with the server side refresh token, which is not good practice, but that seems not to be what you were doing.

The main reason I had was that by making the API generic so that it supports this very specific flow is creating precedence for adding all types of cases specific to different providers. Adding a generic field also leads to lack of type safety and potential vulnerabilities down the line. I find that in general auth flows are very often customized by providers and supporting all specific cases out of the box is hard. In this case, this Google flow is a hybrid of implicit and authz code and so it fits into neither Credential or CredentialToken.

We should probably come up with something specific for Google that supports this specific flow.

[crspybits]

Thanks, @gtaban. Please let me know if I can help out.

[crspybits]

I was updating the Kitura versions for my project, and I'm looking back at this issue. @gtaban, has any progress been made with this? For the time being, I'm still working with my own /CredentialsGoogleToken fork but would rather get away from that.

Thanks,
Chris.

[hotbit9]

you can write a middleware to extract the desired info from the request, and put that middleware right after the Credentials middleware.

Hi @irar2 How can this be accomplish ? I need to get some info from the header request from various codable routes. Any help ? Thank you!

[ianpartridge]

Hi, to get access to HTTP headers in Codable routes you can use a type-safe middleware.

See https://developer.ibm.com/swift/2018/06/05/type-safe-middleware/ for an intro and do join our Slack if you have questions!

[hotbit9]

Thanks @ianpartridge ! I got it working !