Providing/ implementing a callback uri?

[anthgur]

In many of the examples, the client-config map has a callback path, but they aren't defined in the routes.
Google Handler example config/routes

If I had some credential-fn, and config to be passed to friend/authenticate like this:

(defn my-cred-fn [refresh-token]
  (store-in-db refresh-token))

(def oauth-config 
  {:allow-anon? true
   :workflows [(oauth2/workflow
                 {:client-config client-config
                  :uri-config uri-config
                  :config-auth config-auth
                  :credential-fn my-cred-fn})

Where and when would it be called? In regards to #20, how would I know when a refresh token was passed to my-cred-fn? Is the callback uri where a custom credential-fn would be executed? How do you go about implementing one of these callbacks?

Thanks, I realize there are a few questions here, but I think they are connected.

[ddellacosta]

@anthonyurena Please take a look at item 5 from this section of the README, it answers this in more depth--and let me know if anything is still unclear.

That said, with stuarth's help I want to build something a bit more all encompassing that lets the library end-user inject a function at the point of receiving the oauth2/OpenID connect token data at the end of the signin process. Will get this updated ASAP.

[anthgur]

I'm trying to learn oauth as well as the friend workflow pattern at the same time, so forgive me if my issue is just lack of understanding.

It seems like credential-fn acts differently in the case of this library in the sense that it parses auth tokens from providers rather than verifying credentials with some authority as with vanilla friend (ex. username/password stored in a db). I wasn't sure if I was injecting it into the right location, but looking at #25 it seems like I was (please correct me if I'm wrong).

My use case is that I need to store refresh tokens so my server can make privileged requests on behalf of users. Is it within the scope of this library to have a workflow (or some other functionality) for obtaining access tokens from previously stored refresh tokens? That's something that I will need to implement anyway, so if it's something that would add value to the library I could submit a pull request.

Also, how does the callback uri come into play?

Thanks for pushing to add these features, I really do appreciate it.

[ddellacosta]

You're right that the credential-fn works differently in friend-oauth2 than in the usual friend workflow. It doesn't even do any parsing though; by default it just hands back an identity map with the access token present.

The problem right now is that there is no way for the library end user to get ahold of the refresh token (or anything else, including the new ID token that OpenID Connect protocol provides) that is returned. Sorry I wasn't more clear about this. Unfortunately the credential-fn is not going to help; it only provides access to the access token.

What stuarth is working on is exactly what you need, minus actually making requests for new access-tokens. That's something you could probably help contribute to if you are interested--maybe bring it up in #25 if so.

That said, as a stopgap you can grab his code, or even write your own extension of the workflow--there's really not that much to it--and at such a point where the feature is actually pushed you can just swap in the new version of friend-oauth2, if that's palatable to you.

Sorry I don't have much better advice at this time--but I'm happy to help you get this working for your own needs, and of course please comment on #25 if you have any thoughts!

RE: callback uri, that's what tells the provider where to redirect (back to your site) once they've done the authentication flow on their side with the user--so friend-oauth2 needs to know that to pick up requests coming in, to complete the oauth2 workflow on this end.

[anthgur]

Thanks for clarifying, that was really helpful. I'll comment on #25 if I have any more questions/comments IRT refresh tokens, but I do have another question about callback uris.

How exactly does the workflow determine that the request is a callback?

I see that the workflow checks the request for a code and the anti-forgery token from the session. So this section is where the callback handling takes place, and friend-oauth2 is listening for the callback uri behind the scenes in this section?

[ddellacosta]

I don't know why you asked me how it works, you just explained it yourself. ;-)

[ddellacosta]

BTW, if you feel like this is cleared up I'll go ahead and close this (or you can). Let me know.