0

I'm starting a project using Azure as our serverless framework.
The project consists of two separate frontends applications that must talk to some backend services, some will be made by me and others by other teams.
I plan to implement a BFF between the frontends and the other domain services.
My question is regarding authorization. I can think of two ways:

  1. Forward token from BFF to domain services
    a. FE requests token from Auth provider
    b. FE sends token to BFF
    c. BFF validates token and scopes
    d. BFF adds token to http header when calling the domain services

  2. BFF requests and caches machine 2 machine tokens to call other services
    a. BFF is configured as a client of other services
    b. BFF request token and caches/refreshes it periodically
    c. FE requests token from Auth provider
    d. FE sends token to BFF
    e. BFF validates token and scopes
    f. BFF uses one of its own tokens to call the other services

I can see pattern one being way easier to implement, since there is only one token, which grants access to the BFF and to other services. But I'm not sure if it is a proper pattern.
Can someone share their experience on the subject?

1 Answer 1

2

Pattern 1 is the approach you want. Create a token by calling your Auth service, and use that token when validating within any other service. You dont want to cache tokens anywhere in your infrastructure - it defeats the purpose of using them and becomes a potential security weak-point (because if someone hacks you they can extract all the tokens for whoever they want and impersonate users - true, they could do that with user/pass creds, but its easier to secure those in one place than a whole bunch of servers caching tokens)

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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