Howdy, Stranger!
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 115 Navision DOS
- 854 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 615 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 304 Dynamics CRM
- 109 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 993 SQL General
- 384 SQL Performance
- 34 SQL Tips & Tricks
- 34 Design Patterns (General & Best Practices)
- Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.7K General
- 1.1K General Chat
- 1.6K Website
- 79 Testing
- 1.2K Download section
- 23 How Tos section
- 260 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions
Service to service auth and multiple api customers
wilk_u
Member Posts: 94
Hello,
guys I would like to investigate such case:
- BC Api exposed with s2s auth i.e. creating webshop integration
- is it possible using azure and BC to distniguish customers i.e. register the api with s2s muultiple times but in oauth claims put customer no and use it in bc?
- or the only possiblity in such case would be send some secret unique for customer in contract itself with custom layer of authentication build as an extension
Of courese user impersonation auth is also an option but have 2 drawbacks: ncessity to use refresh token to keep integration running without need to generate new token as old has expired; licensing - each customer 'eats' a license.
I appreciate your thoughts.
Regards
guys I would like to investigate such case:
- BC Api exposed with s2s auth i.e. creating webshop integration
- is it possible using azure and BC to distniguish customers i.e. register the api with s2s muultiple times but in oauth claims put customer no and use it in bc?
- or the only possiblity in such case would be send some secret unique for customer in contract itself with custom layer of authentication build as an extension
Of courese user impersonation auth is also an option but have 2 drawbacks: ncessity to use refresh token to keep integration running without need to generate new token as old has expired; licensing - each customer 'eats' a license.
I appreciate your thoughts.
Regards
0