# Combine security and normal inputs in an endpoint

**URL:** <https://softwaremill.community/t/combine-security-and-normal-inputs-in-an-endpoint/157>\
**Category:** tapir\
**Created:** [March 23, 2023, 7:50am UTC](https://softwaremill.community/t/combine-security-and-normal-inputs-in-an-endpoint/157 "2023-03-23T07:50:02Z")\
**Posts on this page:** 2\
**Page:** 1

<div class="post-metadata">

**Author:** ![andreazube](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/andreazube/32/117_2.png) [@andreazube](https://softwaremill.community/u/andreazube)\
**Post date:** [March 23, 2023, 7:50am UTC](https://softwaremill.community/t/combine-security-and-normal-inputs-in-an-endpoint/157/1 "2023-03-23T07:50:02Z")

</div>

Hello there

Let’s say I have an endpoint like

```auto
endpoint
  .securityIn(auth.bearer[MyIdentityTokenClass])
  .in("toysProducers")
  .in(path[UUID]("toyProducerId")
  .out(jsonBody[Seq[Toy]])

```

The logic I need to apply to this endpoint is

- Check that the token is valid: `MyIdentityTokenClass => A`
- Check that the token is valid for my specific toy producer, i.e. it has read access for that specific resource: `MyIdentityToken, UUID => B`
- The actual server logic: `B => UUID => Seq[Toy]` (B would be the response from the last security check)

The problem is, as far as I can tell, security and normal inputs are “segregated”.

I can think of two ways of solving the issue

- Treating the `toyProducerId` as part of the security input, so that I would have an endpoint where `securityInput = (MyIdentityTokenClass, UUID)` and `input = Unit`

- Letting the `securityInput` only deal with the first check and return its own token, then apply the read permission logic in the server logic part

The first solution feels a bit dirty because it’s not clear from the endpoint’s definition that the `toyProducerId` is also used in the implementation logic.

The second one requires me to handle security logic in the implementation logic despite having a dedicated security logic already. Then again, one is authentication and the other is authorization, so it might make sense to treat them differently.

Is there a cleaner approach?  
If not, which of the two I mentioned do you think is most appropriate?

---

<div class="post-metadata">

**Author:** ![adamw](https://dub1.discourse-cdn.com/flex005/user_avatar/softwaremill.community/adamw/32/28_2.png) [@adamw](https://softwaremill.community/u/adamw)\
**Post date:** [March 27, 2023, 12:08pm UTC](https://softwaremill.community/t/combine-security-and-normal-inputs-in-an-endpoint/157/2 "2023-03-27T12:08:16Z")

</div>

Yes, you’re right that the security/normal inputs are segregated. One of the main use-cases for this features is to be able to define reusable endpoints, where the security logic is defined, but the server logic not yet.

So what might help you decide is if there’s multiple endpoints which use the `toyProducerId` for security and if so, if such a partially-applied endpoint definition might be reused.

But in general, not knowing the exact code-base, my first choice would be to go with the second option: performing a validity check in the security logic, and running further endpint-specific security in the server logic. Authentication/authz is also a good discriminator.