context as part of access token #6

Closed
dvv opened this Issue Mar 21, 2013 · 11 comments

Projects

None yet

2 participants

@dvv
dvv commented Mar 21, 2013

Hi!

I would like to drive a store-less auth system -- that is i'd like to encode context in signed encrypted strings. Similar to how they use cookies to store data.
However, the current code infractructure strongly separates access token and context:

associate_access_token(AccessToken, Context) -> ok.
resolve_access_token(AccessToken) -> {ok, context()}.

resolve_access_token/1 is simple to accomodate to my flow, but associate_access_token/2 is not as it just returns fixed atom.
I would have been ok if the backend would be given chance to generate access token from context, say:

associate_access_token(AccessToken, Context) -> ok | {ok, NewAccessToken}.

What do you think: is it ever feasible? Maybe another ways of doing what I need which I don't see?

TIA,
--Vladimir

Contributor

I'm not entirely sure I understand the guts of how you going to achieve store-less auth. Having said that I seen no problem in doing the changes you suggest.

I'd be interested to know more on how exactly it's supposed to work. But feel free to whip up a pull request!

dvv commented Mar 22, 2013

I drive termit for that.

The use case, backend:

associate_access_token(_AccessToken, Context) ->
  % NB: new token is encoded context
  {ok, NewToken} = termit:encode_base64(Context, <<"offline-known-secret">>).

resolve_access_token(AccessToken) ->
  % NB: access token is encoded context, 3600 is TTL
  {ok, Context} = termit:decode_base64(AccessToken, <<"offline-known-secret">>, 3600),

For this to work I changed portions of oauth2.erl like:

    % WAS ok = oauth2_backend:associate_access_code(AccessCode, Context),
    AccessCode3 = case oauth2_backend:associate_access_code(AccessCode, Context)
    of
      ok -> AccessCode;
      {ok, AccessCode2} -> AccessCode2
    end,
    oauth2_response:new([], TTL, ResOwner, Scope, [], AccessCode3).

I wonder if it's elegant enough to merge master

Contributor

I see. Nice. How about instead making the Access Token-generation pluggable?

dvv commented Mar 22, 2013

You mean delegate generation to backend?

Contributor

I'm thinking that you can optionally specify in your app.config a module (which implements an access_token behavior) which can be used for generating access_token's. That would be an elegant solution solving both your problem as well as giving us a way to plugg different access_token generation algorithms.

dvv commented Mar 22, 2013

Sounds good. Wonder if you could do that?

@bipthelin bipthelin added a commit that referenced this issue Mar 25, 2013
@bipthelin bipthelin Make token generation pluggable
This should fix issue #6 . To change how tokens are generated you can
specify in your app.config a module that should handle the token
generation. The config looks like:

```erlang

    [
        {oauth2, [
            {token_generation, YOUR_TOKEN_GENERATOR}
        ]}
    ].

```

The eefault token generator is called `oauth2_token`. To implement your
own you should create your own module exporting one function
`generate/0`.
9501d50
Contributor

Take a look at the branch 'bt-pluggable-access_token' and see if it works for you

@bipthelin bipthelin added a commit that referenced this issue Mar 28, 2013
@bipthelin bipthelin Make token generation pluggable
This should fix issue #6 . To change how tokens are generated you can
specify in your app.config a module that should handle the token
generation. The config looks like:

    [
        {oauth2, [
            {token_generation, YOUR_TOKEN_GENERATOR}
        ]}
    ].

The default token generator is called `oauth2_token`. To implement your
own you should create your own module exporting one function
`generate/0`.
c8abcf7
Contributor

Try the branch again.

dvv commented Mar 28, 2013

Seems good now! Looking for a way to use it in my https://github.com/dvv/pecypc/blob/master/src/pecypc_oauth2.erl . oauth2_example seems a bit dated (elder cowboy) and doesn't provide for the most complex flow of authorization grant.
I tried my best to make use of all common flows but am still noob in erlang, so I would appreciate if you put some review on the code ;) tia

Contributor

I've merged this to master now.

dvv commented Apr 15, 2013

Thank you. Time to get rid of my own impls.

@bipthelin bipthelin closed this Apr 15, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment