I am using REST API as a presentation layer of a DDD project. In order to secure API calls, I am using token based security.

Security in Web APIs-Basic Authentication and Token based custom Authorization in Web APIs using Action Filters.

If an API user administration context is persisted by a different API or BCs (depending on design), would it be considered as breaking DDD if a BC actually accesses outside resource (either 3rd party API or other BC in DDD) in order to check user credentials?

  • 2
    No, quite the contrary: user administration and most likely not part of the business domain, and therefore by all means SHOULD be done by a different domain. Credentials in general are usually an application layer concern, not a domain layer concern. Apr 29, 2016 at 14:43
  • A thing to notice: when you switch to discussing administration/security/etc, your audience of domain experts changes dramatically. That's a big hint that you are crossing a domain boundary. Apr 29, 2016 at 15:22
  • @AlexanderLanger Shouldn't BC be isolated from any outside sources in order to keep its autonomy? May 23, 2016 at 8:48
  • @DarioGranich Yes. Hide any "outside" access that you need to check user credentials behind an interface (in the domain language), use Inversin of Control (Dependency Injection) and a anticorruption layer to keep the BC autonomous while still being able to query outside sources. May 23, 2016 at 17:54

1 Answer 1


Apart from what Alexander Langer said, there are not only good reasons for, but actual security policies for going even further and don't even hold any kind of credentials or temporary tokens in your domain logic.

Practically speaking (and I apologise for not knowing DDD or the exact case well):

  • the domain logic (BC, WebService, whatever) rarely has to really hold the credential
    • for most of the tasks the logic can rely on the above security layer (e.g. a bit smart reverse proxy which it mutually trusts based on client-server transport security) to sort out most of the the nasty security stuff
    • don't expose the business part to the consumer, put it behind the secured part
  • let your logic rely just on the fact, that the security layer gave it the correct user identifier and the set of permission identifiers relevnt for the particular domain (BC)
    • trust your security layer (and security experts) they do their security work well
    • don't trust the business code in stuff that it is not responsible for
    • expect the worst security flaws from your programmers, because it just happens
  • it would be "too much info" for a domain logic to know the credential (even in form of token), I don't think that the business code ability to impersonate the user "all over the place" is needed.
    • aim for absolutely minimal information, just wht is needed to perform the task.
    • the task is business/domain, it is about the user and his stuff. It is not about his credentials, that would be domain of the security layer.

To imagine the potential implications of a security decision of this kind, consider the fact, that an "information" stored in a token/credential/user-id is not just the binary content of the data, but everything reachable from this data using today's or future possibilities (cracking the hashes, crawling the othe parts of the system using the token by an attacker etc.)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.