Jak bezpiecznie uzyskać dostęp do mojego API z mojej aplikacji internetowej?

Question

Mam API. Niektóre z nich są ograniczone do dostępu z aplikacji firm trzecich przez OAuth.

Mam również aplikację internetową. Użytkownicy mogą się zalogować i zobaczyć swoje prywatne informacje.

Interfejs API wywoływany jest również z aplikacji internetowej. Moje pytanie brzmi: jaki jest dobry sposób na uzyskanie dostępu do API za pomocą środków bezpieczeństwa.

1. Third party applications -> OAuth 

2. My own web application -> ??? 

Moja aplikacja internetowa używa identyfikatora sesji do uwierzytelnienia. Domyślam się, że przeniesienie identyfikatora sesji z nagłówkiem HTTP może być dobrym pomysłem, ale nie mam pewności.

Dla exmaple ...

$ curl -X PUT \ 
     -H "X-Sample-Application-Id: "My own web application's ID" \ 
     -H "X-Sample-Session-Token: yeoql2dvn7whpm4tbe61viscv" \ 

Jeśli API otrzymania tego żądania, należy użyć sesji dla uwierzytelniania zamiast OAuth i identyfikacji użytkownika ....

Każda pomoc będzie mile widziane.

Dzięki

.. Znalazłem podobne pytania

Questions About Consuming Your Own API with OAuth

---

Update1

Niektórzy mówią JWT (Json sieci Token) jest dobry.

https://auth0.com/blog/2014/01/07/angularjs-authentication-with-cookies-vs-token/

http://blog.mitsuruog.info/2014/08/jwtjson-web-tokenwebapicredential.html

---

Update2

może będę w stanie wykorzystać "resource Hasło właściciela Poświadczenia" OAuth za

https://www.ipa.go.jp/security/awareness/vendor/programmingv2/contents/709.html

Albo ... „Client Crede Ntials grant "wygląda o wiele lepiej.

Answer 1

Mam zamiar trochę o tym opowiedzieć, ponieważ jest to dobre pytanie, a wokół niego jest wiele zamieszania - tak go tu przy mnie.

Jeśli interfejs API, który próbujesz chronić, będzie używany wyłącznie przez osoby korzystające z aplikacji działających po stronie serwera, a nie przez osoby trzecie, zdecydowanie zalecam używanie podstawowego uwierzytelniania HTTP w celu zabezpieczenia usługi interfejsu API. .

Sposób ten działa jest bardzo prosta:

• Dla użytkownika (-ów), wygenerować parę kluczy API (y), które składają się z identyfikatora i tajne. Klucze API są synonimem nazwy użytkownika/hasła. Po prostu generuj losowe identyfikatory/tajne wartości za pomocą biblioteki UUID.

• Po uwierzytelnieniu w usłudze API podaj te referencje API w nagłówku autoryzacji HTTP, aby się zidentyfikować.Oto jak to wygląda przy użyciu curl:

  $ curl --user my-api-KeyID: my-api klucz tajny https://api.myservice.com/blah

Co to wielki temat podstawowe Auth jest to, że:

• Jest bardzo prosty w implementacji.
• To dobrze zdefiniowany standard.
• Dopóki wysyłasz żądania przez HTTPS i nie publikujesz kluczy API, powinieneś być bezpieczny.

Teraz - jeśli tworzysz usługę API, w której chcesz uwierzytelniać użytkowników z różnych środowisk (nie tylko aplikacji po stronie serwera), naprawdę musisz korzystać z protokołu OAuth2.

To jest to, do czego został zaprojektowany.

Protokół OAuth2 może uwierzytelniać użytkowników na różne sposoby, ale w rezultacie jest dość skomplikowany. Dodawanie OAuth do witryny może być wyzwaniem, nawet jeśli korzystasz z popularnych bibliotek/itp

Oto jak działa OAuth (szybki rozpad):

grantu Hasło

hasło przepływ w OAuth to miejsce, w którym wymieniasz nazwę użytkownika/hasło dla tokena dostępu (zazwyczaj JWT). Następnie używasz tokena dostępu w nagłówku autoryzacji HTTP, aby identyfikować się z usługą API.

To właśnie robi większość ludzi budujących SPA z Angular/React, a także aplikacjami mobilnymi.

poświadczenia klienta Grant

Klient Poświadczenia płynąć miejscu można wymienić klucz API (podobnie jak podstawowy auth) na token dostępu. Następnie używasz tokena dostępu w nagłówku autoryzacji HTTP, aby identyfikować się z usługą API.

To właśnie robią ludzie budując aplikacje po stronie serwera dzięki OAuth.

niejawny Grant

Ten przepływ jest to, co widać po zalogowaniu się na pewnym miejscu jak Facebook. Klikasz przycisk, zostajesz przekierowany do innej witryny, aby uwierzytelnić/zaakceptować uprawnienia, a na koniec wracasz do głównej witryny z tokenem dostępu, którego używasz do identyfikacji siebie. To NIE jest idealne dla usług API.

Autoryzacja Kod Grant

Ten przepływ jest dokładnie tak, jak przepływu niejawnym, chyba że wrócisz kod autoryzacyjny, który następnie zamian za token dostępu, który służy do identyfikacji siebie. To NIE jest idealne dla usług API. Jest nieco bezpieczniejszy.

Jeśli zamierzasz korzystać z protokołu OAuth ze względu na swój przypadek użycia, zdecydowanie polecam sprawdzenie dostawcy uwierzytelniania, takiego jak Stormpath.Automatyzują wiele z tych rzeczy i rozwiązują wiele komplikacji związanych z OAuth.

W przeciwnym razie udziel podstawowe zezwolenie!