From https://openid.net/specs/openid-connect-core-1_0.html#Consent

3.1.2.4 Authorization Server Obtains End-User Consent/Authorization

Once the End-User is authenticated, the Authorization Server MUST obtain an authorization decision before releasing information to the Relying Party. When permitted by the request parameters used, this MAY be done through an interactive dialogue with the End-User that makes it clear what is being consented to or by establishing consent via conditions for processing the request or other means (for example, via previous administrative consent). Sections 2 and 5.3 describe information release mechanisms.

Since this is "MUST", I believe it would be great if boruta includes the consent phase as configuration option.

boruta-server has it as a part of boruta_identity (link) - btw.

Hello, sorry to create this issue, I have read your project but I could not be able to find what method you are using to create code for redirect url and access/refresh token without jwt.
the other question is why you did not use Plug encryption for code not access token?
Thank you

https://openid.net/specs/oauth-v2-form-post-response-mode-1_0.html

Support for response_mode=form_post

Hi! I'm starting to use Boruta, I really appreciate all the hard work that went into this library?

I'm wondering if there are any plans or ideas on supporting users of the application being the owners of a Client.
As far as I understand, with Boruta you can create a Client, but that client is not associated to a user account.

I'd like for an application to be associated to a user, such that I can show in the consent page who is the owner of the application, as well as to let the third party app developer actually manage it.

Is there a way to do this that I'm missing, or is this intended to be implemented by the library user with additional tables?

Thanks!

It seems that some Clients require the "use" field on JWKs in order to find the matching signing keys from the JWKS, most likely as a way to prevent encryption keypairs from being used to verify signed tokens or vice-versa.

I am not sure if this is a requirement as per the OpenID Connect spec; if it is not, it would probably be preferable to correct the clients instead.

RFC 7517 (4.2) does specify it as "optional, unless the application requires its presence". OpenID Connect Core 1.0 makes no mention of the requirement of such a field (and considering the certifications, I would expect it is not required).

Feel free to ignore this issue, as it seems to be Client-specific behaviour that is most likely wrong.

Hi,

i've migrated my existing boruta backed app to phoenix 1.7 and wanted to share the diffs so that you can either pull them back into your generators or we can document them here for others to use. It is simply going through your docs step by ste. the only thing i added is a phx.gen.json step so we have a API to test against.

Here is the diff: norbu09/boruta_auth_phx_1_7@ddc24cf

cheers
Lenz

It uses 1024-bit key, which may not be suitable for alg (e.g. RS256 in the client creation doc.).

Is Boruta.Oauth.Client's id_token_signature_alg for id_token_signed_response_alg in the spec? The spec says its default should be RS256 (if omitted) but Boruta uses RS512 for new client. It's not "against" spec but I'm wondering why it choose RS512.

We may introduce an option for the default key size of generated key pairs.

Seems to happen when compiling the file views/oauth_view.ex, I am not sure what causes it (it might be because phoenix_view is missing from the dependencies)

  1) test compiles files without any errors (Mix.Tasks.Boruta.Gen.ControllersTest)
     test/mix/tasks/boruta.gen.controllers_test.exs:24
     ** (CompileError) nofile:2: module Phoenix.View is not loaded and could not be found
     stacktrace:
       (elixir 1.14.3) src/elixir_expand.erl:90: :elixir_expand.expand/3
       (elixir 1.14.3) src/elixir_expand.erl:536: :elixir_expand.expand_block/5
       (elixir 1.14.3) src/elixir_expand.erl:40: :elixir_expand.expand/3
       (elixir 1.14.3) expanding macro: Kernel.use/2
       nofile:2: Boruta.Support.WebModule.OauthView (module)
       (boruta 2.3.0) expanding macro: Boruta.Support.WebModule.__using__/1
       nofile:2: Boruta.Support.WebModule.OauthView (module)
       (elixir 1.14.3) expanding macro: Kernel.use/2
       nofile:2: Boruta.Support.WebModule.OauthView (module)

This is with macOS 13.3 on Apple Silicon (aarch64) and Elixir 1.14.3, installed from Homebrew. (Erlang/OTP 25 [erts-13.1.5] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit] [dtrace])

https://github.com/malach-it/boruta_auth/blob/2.3.2/lib/mix/tasks/boruta.gen.migration.ex#L104

This makes docker compose run stuck on the first run (which generates migrations)

Hi @patatoid, first I would like to thank you for such an amazing contribution to the Elixir ecosystem!

I do have one question regarding the OpenID Connect Discovery 1.0 spec. As I'm sure you're aware, this spec adds an additional layer specific to identity.

What I am most interested in specifically is the use of acr and amr, which is used to specify and indicate the type of authentication used to/for the RP. This is useful if as a RP you require that a user authenticates with a second-factor.

My question is, given the current state of the library, is it possible to make use of these attributes and metadata even if it's implemented at the application layer? (Ex: can you add additional attributes to the id token that get signed?)

Thank you! 🙏🏻

Hi! First of all thanks again for this amazing library!

Sometime around April/May we started experiencing frequent disconnects from our OAuth clients due to tokens becoming invalid
Looking at the tokens, it seems that they are being revoked almost immediately after they are created:

No changes to the boruta integration were made(and it's probably this started happening earlier but we didn't catch it)

Could this be related to the replay attack fix in 97f296e?

@patatoid sorry for the slew of new issues recently, but as I discover more about the library, the more I am trying to figure out!

Is there a way to extend the clients to include additional data? For example, an image (for a consent page), or other attributes that could be used for other things that fall outside the scope of this library?

I know you're working on boruta_server which appears to maybe address some of this — I noticed a consent page — but I haven't noticed if you're maybe doing anything more with the clients that falls outside the scope of authorization. (Ex: showing a list of clients a user account has authorized)

Oauth2 contains an extension to use a device code for devices that do not have a (web)ui. This grant type (and everything else required) is not available.

I would love if the device code flow would be implemented, but It could be a good start, to allow grant extension and not restrict on the fixed grant set (https://www.rfc-editor.org/rfc/rfc6749#section-4.5).

https://www.rfc-editor.org/rfc/rfc8628#section-3.4