Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

context as part of access token #6

Closed
dvv opened this Issue · 11 comments

2 participants

@dvv

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

@bipthelin
Owner

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

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

@bipthelin
Owner

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

@dvv

You mean delegate generation to backend?

@bipthelin
Owner

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

Sounds good. Wonder if you could do that?

@bipthelin bipthelin referenced this issue from a commit
@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
@bipthelin
Owner

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

@bipthelin bipthelin referenced this issue from a commit
@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
@bipthelin
Owner

Try the branch again.

@dvv

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

@bipthelin
Owner

I've merged this to master now.

@dvv

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

@bipthelin bipthelin closed this
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.