Какие распространенные способы аутентификации можно реализовать в Go-приложениях?

А, слушай, вот это тема — как в гошечке пользователей опознавать, чтобы они не лезли куда не надо. Тут, блядь, вариантов дохуя, и каждый со своими приколами. Сейчас разложу по полочкам, но сразу предупреждаю — если выберешь криво, потом сам будешь ебаться с последствиями.

1. Basic Auth — проще пареной репы, но и дырявый как решето. Это когда логин-пароль в каждом запросе таскают, закодированные в Base64. Типа "я свой, впусти".

• Чем хорош: Реализовать — раз плюнуть. Серверу вообще похуй, состояния никакого не хранит.
• Чем говён: Если без HTTPS — всё, пиши пропало, перехватят на раз-два. Для чего-то серьёзного — вообще никуда не годится.

func basicAuthHandler(w http.ResponseWriter, r *http.Request) {
    user, pass, ok := r.BasicAuth()
    if !ok || user != "admin" || pass != "secret" { // Пример проверки
        w.Header().Set("WWW-Authenticate", `Basic realm="Restricted Area"`)
        w.WriteHeader(http.StatusUnauthorized)
        return
    }
    // Действия для авторизованного пользователя
    fmt.Fprintf(w, "Welcome, %s!n", user)
}

Вот, смотри, весь код. Но это как замок на шкафчике в раздевалке — от честных людей.

2. JWT (JSON Web Tokens) — модно, молодёжно, но свои косяки есть. Тут после входа сервер выдаёт токен — такую, блядь, цифровую бумажку с печатью. Клиент её потом при каждом обращении предъявляет.

• Плюсы: Серверу опять похуй, stateless. Масштабируется на ура. В саму бумажку можно полезную хуйню запихнуть (типа ролей пользователя).
• Минусы: А главная засада — пока срок годности не вышел, отозвать эту бумажку нихуя не получится (разве что чёрный список вести, но это уже гемор). И хранить её на клиенте надо как зеницу ока.

import (
    "github.com/golang-jwt/jwt/v5"
    "time"
)

var jwtKey = []byte("your_secret_key") // Используйте надежный ключ!

type Claims struct {
    Username string `json:"username"`
    jwt.RegisteredClaims
}

func generateJWT(username string) (string, error) {
    expirationTime := time.Now().Add(24 * time.Hour)
    claims := &Claims{
        Username: username,
        RegisteredClaims: jwt.RegisteredClaims{
            ExpiresAt: jwt.NewNumericDate(expirationTime),
            IssuedAt:  jwt.NewNumericDate(time.Now()),
        },
    }
    token := jwt.NewWithClaims(jwt.SigningMethodHS256, claims)
    return token.SignedString(jwtKey)
}

Красиво, да? Но помни — если секретный ключ утечёт, то подделать эти токены — раз плюнуть. И да, your_secret_key надо менять на что-то посерьёзнее, а не эту хуйню.

3. OAuth2 — когда лень своих пользователей заводить, пусть Гугл с Гитхабом пашут. Это когда ты такой: "Хочешь зайти? Давай через свою учётку вон в том сервисе". Пользователь тебе пароль не светит, а даёт разрешение забрать его данные.

• Плюсы: Пользователям — удобно, тебе — безопасно (пароли не твоя головная боль). Интеграция с большими дядьками.
• Минусы: Реализация, блядь, сложнее. И ты становишься зависим от этих дядек — если у них сдохнет авторизация, и у тебя всё встанет.

import (
    "golang.org/x/oauth2"
    "golang.org/x/oauth2/github"
)

// Пример конфигурации OAuth2 для GitHub
var githubOauthConfig = &oauth2.Config{
    ClientID:     "YOUR_GITHUB_CLIENT_ID",
    ClientSecret: "YOUR_GITHUB_CLIENT_SECRET",
    RedirectURL:  "http://localhost:8080/auth/github/callback",
    Scopes:       []string{"user:email"}, // Запрашиваемые разрешения
    Endpoint:     github.Endpoint,
}

func handleGitHubLogin(w http.ResponseWriter, r *http.Request) {
    url := githubOauthConfig.AuthCodeURL("random_state_string", oauth2.AccessTypeOffline)
    http.Redirect(w, r, url, http.StatusTemporaryRedirect)
}

Вот, пользователя на Гитхаб швыряешь, а потом он назад с кодом возвращается. Дальше уже твоя работа — код на токен менять.

4. Сессии (Session-based) — классика жанра, старая добрая и stateful. Пользователь зашёл — сервер создаёт для него сессию (запись в базе, в редисе, да где угодно) и даёт на руки только её ID (обычно в куках).

• Плюсы: Сессию в любой момент можно прибить — и пользователь вылетит. Можно хранить на сервере овердохуищу данных о нём.
• Минусы: Сервер теперь должен помнить состояние, ёпта! Масштабировать сложнее — нужно общее хранилище сессий для всех инстансов. И да, CSRF-атаки тут как тут, если не защищаться.

// Пример использования пакета gorilla/sessions
// store = sessions.NewCookieStore([]byte("super-secret-key"))

// func loginHandler(w http.ResponseWriter, r *http.Request) {
//     session, _ := store.Get(r, "session-name")
//     session.Values["authenticated"] = true
//     session.Values["userID"] = "user123"
//     session.Save(r, w)
//     http.Redirect(w, r, "/profile", http.StatusFound)
// }

Старый, добрый, проверенный способ. Но чувствуешь подвох? Всё держится на этом super-secret-key. И если серверов несколько, то с куковым хранилищем будет пиздец, надо переходить на БД или Redis.

Итог, ёпта: Выбирай с умом. Хочешь быстро и для внутренней админки — Basic over HTTPS. Нужно масштабироваться и без состояния — JWT, но готовься к танцам с отзывом токенов. Лень возиться с пользователями — OAuth2. А если нужен полный контроль и возможность в любой момент вышвырнуть пользователя — сессии, но готовь общее хранилище. Всё зависит от того, что за проект и насколько там всё серьёзно. Не охуей с выбором!