Thanks for putting a new version out! Could you elaborate on what “handle userinfo signed responses” means exactly?
Hi @linusdm
As for OpenID Connect core specification, userinfo responses MAY be signed depending on the client configuration. Here the clients contain a userinfo_signed_response_alg attribute that helps to take into account such signatures.
Values vary between nil | “HS256” | “HS384” | “HS512” | “RS256” | “RS384” | “RS512”, knowing that HS* algorithms take the client secret as the secret for the AES signature and RS* algorithms take the client associated key pair for the RSA signature.
When signed, the response consists of a JWT that encapsulates the JSON containing the ID token claims to be exposed.
1 Like
Hi @pknoth,
thanks for an amazing lib, love it and use it currently in a phoenix 1.6 app. i am migrating to 1.7 at the moment and have some issues with it. do you know of anyone who has a working 1.7 setup that i could compare notes with?
happy to write up what i did so far to help others 
cheers
Lenz
Hi @norbu09 !
Thank you for your support and interest in my work.
You definitely can open an issue on GitHub to get on further investigations, I am not familiarized with phoenix 1.7 and do not know any developer using it.
Happy coding
1 Like
Hi @norbu09
I recently integrated Boruta in a 1.7 phoenix application. There are a few things you have to take care of, that don’t work out of the box when using the mix generators of Boruta. But it’s very doable if you take a few minutes to make the required changes. The biggest hurdle was about the Phoenix views that are now not available anymore in a default generated 1.7 application.
If you have any specific questions, shoot, I might be able to help.
hi @linusdm,
thanks for getting back to me
i have all pages working i think but currently all auth requests redirect to the logged in page for some reason, no way to make them redirect back in oauth authentication workflows.
calls go:
- /oauth/authorize
- /users/log_in
- /dashboard (my app endpoint)
Boruta.Ecto.OauthMapper.Boruta.Ecto.Client.to_oauth_schema/1 is coming back with an auth error even though the user is logged in so some wiring up is not working.
no idea why, same for logged in users and logged out users. i am missing something trivial, i am sure
cheers
Lenz
ok, got it working and documented it here: Phoenix 1.7 compatibility · Issue #7 · malach-it/boruta_auth · GitHub
relevant repo is here: GitHub - norbu09/boruta_auth_phx_1_7
hope it helps anyone else, in case i missed anything please let me know and i’ll pull it back in
1 Like
Nice! That’s more or less the changes that I did too. I’m still curious what the issue was that you reported yesterday. I didn’t stumble upon that specific ecto-related error.
it was actually trivial. i forgot to migrate some of the oauth controller, the token refresh didn’t work and everything fell apart. Going through the tutorial on a fresh phx.new showed the error
as always, trying to replicate the error is the best way to find it.
1 Like
Hello, nice library, interesting to see hexagonal architecture in this context. I’m this library on one project, but have problem adding custom claims (resource/object id). I did not find any thing regarding that in documentation. Is this possible without rewriting some modules from this library?
Hi,
Thank you for your interest in the library!
You can add extra claims to the resource owner in the application layer as described in the type of Boruta.Oauth.ResourceOwner (https://github.com/malach-it/boruta_auth/blob/master/lib/boruta/oauth/schemas/resource_owner.ex). Once added, they will appear in the resulting id token. If you find the courage to document the process it would be a great contriution
Thank you for response. The issue is that this is regarding OAuth2 and not OIDC, so I need them in access token, also, would not like to store them in resource_owner since resource id is unique per access token generated. One resource owner could grant multiple access tokens with different resource id’s.
In order to modify access tokens, you should have a look at Boruta.Oauth.TokenGenerator behavior (https://github.com/malach-it/boruta_auth/blob/master/lib/boruta/oauth/token_generator.ex) you would be able to generate access tokens at your convenience, I think that you need here to make them as JWT as claims are part of that specification. Then you would be able to inject the implementation in the configuration (https://github.com/malach-it/boruta_auth/blob/master/lib/boruta/config.ex) of the server.
This is where I’m now, but have problem to get that claim to that function, resource owner is nil there, probably should preload it during normal situation, but I’m using that generated code that is mapping user to resource owner. Will check it later today.
I think the issue comes from the fact that the resource owner is not provided while authorizing the request in https://github.com/malach-it/boruta_auth/blob/master/lib/boruta/oauth/authorization.ex. The resource owner should be present in implicit requests as #343. I think if you provide the resource owner also from code requests from preauthorization in #192 then in token creation on #215, it would be propagated to the adapter and the generator. I do not have the ability to give it a try now, I keep you updated when I would be able to do so.
I already found out issue, I think default phoenix generated (actually not sure if collegue changed this or it is how it is generated) is not actually saving resource owners but retrieving user and mapping user to resource owner, which is nice solution, so for this use case I need to extend token struct to actually save resource owner and then I can fill that claim from extra claims. Thank you for assistance
Also I would like to ask, I’m curious about that pattern where to integrate this library I have to implement behaviour and then pass module implementing that behaviour to preauthorize/authorize/token callback:
oauth_module().preauthorize(conn, resource_owner, __MODULE__)
Is not it little overcomplicated given the callback function are called at the end of function execution and then is control returned to place of calling. Why is this better than simply return ok/error tuple?
I agree it looks a little complicated, it is called dependency inversion (the D from SOLID principles). As it, the application layer is bound to the domain by an interface and not the inverse by being bound to the domain implementation. The application layer does not need to know anything but the interface that is to be implemented to use the business of the domain.
On top of that, result tules can be complicated if there are more than ok/error responses.
Still, I see that you get benefit that in the future, if you maybe want to add some steps after confirmation success to put something in the conn, you can without change of API, but again, you could simply put it to conn and return conn in ok tuple. What kind of flexibility/modularity it is adding in this case? I disagree you get benefit over return tuples because you still need to pattern match on error callback. For instance I understand using adapters in case of storage just not in this case. Sorry if I’m to arguable, I spend using ex_oauht_provider for last several years and needed to hack it a lot for instance because I was required to support pkce flow and some custom claims, scopes with limited grant flows and other stuff
As you said in more complicated cases, it is quite useful. I own a standalone server using boruta and need such capabilities as in https://github.com/malach-it/boruta-server/blob/master/apps/boruta_web/lib/boruta_web/controllers/oauth/authorize_controller.ex
But still you can bypass the OAuth module and use a with/case way of use the domain by implementing the module logic if it helps keeping your architecture congruent.
